Clarification on `Master.execute(threadsafe=False)` - when is it safe to bypass the global RLock?

[tiaanvow]

Hi, thanks for maintaining modbus_tk.

I'm trying to understand the intended use of the threadsafe argument on Master.execute() and the process-global RLock in modbus_tk/utils.py.

My setup:

• Multiple Master instances (TCP and RTU), each owning a separate physical link.
• Each Master is only ever called from a single dedicated IO thread — no Master is shared between threads.
• With ~6–7 concurrent Master instances, threads serialise behind the global RLock in execute(), causing dropouts on unrelated devices.

Questions:

1. Is the RLock in utils.threadsafe_function intended to protect a single Master/socket from concurrent access, or is there shared global state across Master instances that it's also guarding?
2. If each Master is confined to one thread (i.e. the socket/serial handle is never touched concurrently), is it safe to pass threadsafe=False to execute()? Are there any known failure modes — e.g. shared buffers, transaction ID generation, or logging — that could still cause frame interleaving or corruption?
3. Has there been any consideration of making the lock per-Master rather than process-global? Happy to contribute a PR if that direction is welcome.

For context: we're hitting this in a real-time industrial control loop where lock contention on one link causes timing failures on others, so getting this right (rather than just patching it out) matters to us.

Thanks!

[tiaanvow]

We use this in production, and will pay $$ to solve this for us :)

[DmitrySidorow]

just try to use claude. I fixed another modbus library with it

[iKoles-dev]

Opened PR #196 with a per-Master execute lock so separate physical links no longer serialize on one decorator-level lock. It keeps the existing global fallback for shared class-level state like TCP transaction IDs and includes a regression test for concurrent executes on different Master instances.

[SimoneMariaRomeo]

@tiaanvow I can take the paid support slice you mentioned without duplicating the existing PR.

I checked PR #196 locally: it is mergeable, changes the global execute lock into a per-Master lock with global fallback, and python -m unittest discover -s tests -p 'unittest_*.py' passes 86 tests on the PR branch.

For EUR 25, I can deliver a production-focused validation packet for your setup:

• review whether Use per-master lock for execute #196 safely covers separate TCP/RTU Master instances without hiding transaction-id or shared-state risks;
• add a focused stress/regression test or follow-up patch if the current PR leaves a real gap;
• post the findings publicly here so the maintainer and your team can act on them.

Stripe payment link: https://buy.stripe.com/14AaEQ6DZbmF7vBe8YbZe0b

I will treat this as paid work only if the Stripe checkout is paid. No device credentials or private production data are needed for the first pass.