Is modbus_read_registers considered thread safe?

698 views
Skip to first unread message

levi.k...@gmail.com

unread,
Jun 7, 2016, 11:46:31 AM6/7/16
to libmodbus
I am developing a program using libmodbus which opens 16 TCP client connections to a modbus server (potentially on same or different IPs).  Each thread has a different context created with modbus_new_tcp().  Each thread will periodically read some selection of registers, starting at different bases and using different lengths.  All threads also have a local buffer to hold the read results.  Should it be considered safe to call modbus_read_registers in all my threads without any blocking?

My program was experiencing segmentation faults with several clients communicating.  I have now wrapped a pthread lock/unlock mutex around just the call to modbus_read_registers which seems to be making my program stable again.  I was also not encountering any issues when testing with only a single client communication thread, so whatever problem I have seems to be impacted by threading.

I realize this may just be changing the timing of my program enough to (by chance) prevent other problems which are not apparent to me now; so the question is should this be considered at all necessary by the library?  Can I have multiple modbus_read_registers "in flight" on the network at the same time?

-- Levi Kendall

Tim Carney

unread,
Aug 1, 2016, 4:01:42 PM8/1/16
to libmodbus
Levi,

I'm curious to see what you found out on this topic. While reading through the man page on libmodbus, I saw the comment that the context is thread safe, but looking at the source code I cannot figure out how that can be. I suspect all that is needed is an additional mutex element in the context structure and some supporting code when the context is created and accessed. Can you verify that the problems you saw were related to multiple threads accessing a libmodbus context simultaneously?

-Tim

Levi Kendall

unread,
Aug 1, 2016, 4:15:10 PM8/1/16
to libm...@googlegroups.com
In the end I've narrowed down the problem I had to something else in the program.  Technically my code even looked OK as is, but it probably was from memory use and a lot of C++ strings being passed by value.

The lock helped my program simply by slowing down the rate a few other components could run (as I had suspected), and eventually it would crash, it just lasted for many times as long, which long term testing eventually ran into.

As far as the buffers used by in-flight requests, I think those were locally stored on the stack, so my evaluation seems to be that it actually is fully thread safe after all.


--
Vous recevez ce message, car vous êtes abonné à un sujet dans le groupe Google Groupes "libmodbus".
Pour vous désabonner de ce sujet, visitez le site https://groups.google.com/d/topic/libmodbus/5VBf-v5o2L4/unsubscribe.
Pour vous désabonner de ce groupe et de tous ses sujets, envoyez un e-mail à l'adresse libmodbus+...@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

Stéphane Raimbault

unread,
Aug 2, 2016, 5:08:34 AM8/2/16
to libm...@googlegroups.com
The documentation has been updated (in master) to not state that anymore (thread-safe) because you can't share modbus contexts between various threads w/o proper locking.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "libmodbus".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse libmodbus+...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages