Thread safety

[mgkuhn]

The libserialport documentation says under “Thread safety”:

“Certain combinations of calls can be made concurrently, as follows.

• Calls using different ports may always be made concurrently, i.e. it is safe for separate threads to handle their own ports.
• Calls using the same port may be made concurrently when one call is a read operation and one call is a write operation, i.e. >it is safe to use separate "reader" and "writer" threads for the same port. See below for which operations meet these >definitions.

Read operations: sp_blocking_read(), sp_blocking_read_next(), sp_nonblocking_read(), sp_input_waiting(), sp_flush() with SP_BUF_INPUT only, sp_wait() with SP_EVENT_RX_READY only.

Write operations: sp_blocking_write(), sp_nonblocking_write(), sp_output_waiting(), sp_drain(), sp_flush() with SP_BUF_OUTPUT only, sp_wait() with SP_EVENT_TX_READY only.

If two calls, on the same port, do not fit into one of these categories each, then they may not be made concurrently.”

Julia has claimed thread safety for its I/O operations since release 1.3, so I wonder if we shouldn't aim to ensure the same for LibSerialPort.

To enforce the constraints required above, e.g. for applications where multiple threads send data to the same serial port, we could add to the SerialPort type two new ReentrantLock members:

rlock::ReentrantLock
wlock::ReentrantLock

each to be initialized with ReentrantLock(). And then each call to one of the read operations above will have to be enclosed with corresponding lock(rlock) and unlock(rlock) methods, and equivalently with wlock for the write operations.