Python How to share a serial port with two different threads (Class A, Class B)

Question

Hello guys, thank your for reading.

Well, I have a single python process which is using a serial port (unique resource) which is manage using an instance of a (A=Class A). Exist two different thread initialized using B=Class_B() and C=Class_C(), which are constantly using the serial port resource through the objected already created called.

Class A(threading.Thread):
    #Zigbee serial port handler
    def __init__(self,dev):
        #something here that initialize serial port
    def run():
        while True:
            #listening serial interface
    def pack(self):
        #something
    def checksum(self):
        #something
    def write(self):
        #something

Class B(threading.Thread):
    def __init__(self,SerialPortHandler):
        self.serialporthandler=SerialPortHandler
    def run(self)
        while True:
            #something that uses self.serialporthandler

Class C(threading.Thread):
    def __init__(self,SerialPortHandler):
        self.serialporthandler=SerialPortHandler
    def run(self)
        while True:
            #something that uses self.serialporthandler


def main():
    a=A('/dev/ttyUSB1')
    b=B(a)
    b.start()
    c=C(a)
    c.start()

if __name__=='main':
    while True:
        main()

The problem is obvious, and is that both thread are trying to access the serial resource at the same time. I could use several instances of the same Class A, attaching Lock.acquire() and Lock.release() in the sensitive parts, but the

Could some of you point me to the right way?

thank you in advance

Answer 1

Add a threading.Lock() to class A and make it acquire the lock when using it:

def __init__(self,dev):
    self.lock = threading.Lock()

def read(self):
    self.lock.acquire()
    data = ? #whatever you need to do here to read
    self.lock.release()
    return data

def write(self, data):
    self.lock.acquire()
    #whatever you need to do to write
    self.lock.release()

Answer 2

you could start with something like this:

Class A():
    #Zigbee serial port handler
    def __init__(self,dev):
        self.lock = = threading.Lock()
        #something here that initialize serial port
    def read(self):
        # use flush to wait until all data has been written
        # if you are using pyserial
        self.serial.flush()  
        #something
    def write(self):
        self.lock.acquire()
        #something
        self.lock.release()

Class B(threading.Thread):
    def __init__(self,SerialPortHandler):
        self.serialporthandler=SerialPortHandler
    def run(self)
        while True:
            #something that uses self.serialporthandler

Problem that you can face :

• read() can return false data example: when you are reading from the serial port and another tread have already started writing , you will get only old data; unless you do a flush() before reading so that it will wait until all data is written.

• your biggest problem is when writing data to the serial port ; Locking is necessaries here, but maybe you can need to use Rlock() rather.

• if you want nonblocking operation you can use select() (it's not advices if you use pySerial) or self.lock.acquire(False)

Answer 3

While you could share the serial port using appropriate locking, I wouldn't recommend it. I've written several multi-threaded applications that communicate on the serial port in Python, and in my experience the following approach is better:

• Have a single class, in a single thread, manage the actual serial port communication, via a Queue object or two:
  • Stuff read from the port is placed into the queue
  • Commands to send to the port are placed into the queue and the "Serial thread" sends them
• Have the other threads implement logic by placing things into the queue and taking things out

Using Queue objects will greatly simplify your code and make it more robust.

This approach opens a lot of possibilities for you in terms of design. You can, for example, register events (callbacks) with the serial thread manager and have it call them (in a synchronized way) when interesting events occur, etc.