Multithread safety for single port

[Neuromancer2701]

This is more of question from looking at the code.
I don't see any lock guards in the Serial Port/Stream classes.
So it is just not possible for two threads to share the same port object. e.g. a class variable
because of the all of the limitations on the the objects.
Or is this something that could be improved by adding a lock guard and mutex inside each of the classes? This would allow two threads to share the same port with one blocking until the other is finished.

P.S.- I didn't really know how to ask this question with our cluttering the Issues sorry about that.
Regards,
Seth

[mcsauder]

@Neuromancer2701 , the issue you describe is actually tightly intertwined with this issue: #40

If you can figure out a way to get this work accomplished the proposal you have described would be an excellent bit of functionality to attempt!

NOTE: I've made many attempts at accessing an already opened serial port file descriptor but haven't figured that step out successfully. If you are able to accomplish this let's add it to the library!

[giancarlocp]

I am looking to do a full duplex stream over one port. To process this a Multithread may help.
I have seem the serial_stream_read_write.cpp example where you use two port and a half-duplex to do the job.
@mcsauder Do you have any thought on how to address it?

[mcsauder]

Hi @giancarlocp . The way I've handled this in the past has been with one thread handling all of the read/write operations for the port with data stored in a read buffer and/or a write buffer that are accessible by any arbitrary number of additional threads with appropriate lock guards in place for the shared buffers.

In the example referenced above, each serial stream is opening a separate port, (it is assumed the the ports are physically wired/connected together), so you actually do have full dupliex in that example.

Another good example for you to look at in the library is in the unit test framework:

libserial/test/MultiThreadUnitTests.cpp

Line 56 in 8eabea1

MultiThreadUnitTests::serialStream1ThreadLoop()

Take a look at how the unit tests are structured and see if this gives you any ideas or additional questions that we might be able to help with!

EDIT: Here is a better place to start reading in the unit tests:

libserial/test/MultiThreadUnitTests.cpp

Line 222 in 8eabea1

MultiThreadUnitTests::testMultiThreadSerialStreamReadWrite()

[giancarlocp]

Thanks @mcsauder.
I have two machines and a signal in each one. To send them to the other as fast as possible, I was thinking in one thread to send, where we tie the signal buffer to the serial write buffer, and another thread to do the same with the incoming data/signal. is this the fastest approach? I mean, to get the lowest timing. Or one thread to send/receive is enough to get the fastest speed.

[giancarlocp]

I may misunderstood something. How do we achieve full duplex in one thread? Has the hardware two separate buffers? and does it do the two(send/receive) jobs by itself? can we can use DMA with this buffers? When we use serial_port.write(buffer), and serial_port.read(buffer,...), how many CPU cycles takes this commands? to calculate the minimal timeout to receive a known size buffer, Do it start counting the time when the first bit is received?

[mcsauder]

Hi @giancarlocp , yes, the hardware has two separate buffers, one for the TX line, and one for the RX line, but LibSerial is not operating at the hardware level, it is utilizing the OS allocated memory. If you are looking to use DMA, LibSerial is a littler higher level than what you probably want. LibSerial is meant to run on top of a posix OS, so all the physical layer abstraction is being handled by the OS and not approached by this library.

I haven't looked into performance characteristics like those you inquire about, so I don't have much in the way of answers there.