As per our discussion, I see following issues due to usage of event queue (which is not required IMO)

1. For each port change event, main task reads the port change from config DB (1st read), writes it into the event queue of both the observers (2 writes). Each of the observer then reads the event from their respective event queue(2 reads). So total 3 reads and 2 writes.
2. Since, the same event queue is accessed for write by (main task) and read by observer threads, a lock is a must. For each port change event there will be a total of 4 lock and unlock operations (because of 2 reads and 2 writes in the event queue of observers)

Consider a worst case where there are 36 ports in x4 breakout so a total of 144 logical ports entries in the event queue needs to be added or deleted which means a total of 144 * 4 = 576 lock/unlock operations.

Lets consider an alternative approach, without the event queue. Since, DB allows to share information across multiple process, we can just let the observers listen to CONFIG_DB changes instead of only main thread. This way each observer can fetch the port mapping independently by reading the PORT_TABLE in APP_DB. No queue required and ZERO locks required. Please note, three select() is lightweight operation compared to lock/unlocks. In this approach there will be only 3 reads required compared to 3 reads and 2 writes and additional overhead due to mutually exclusive access to the event queue.