Resource manager query

I was reading the qnx i2c framework and the resource manager has been implemented in both single and multi threaded fashion. what the article says is that it is hard to implement lock on single threaded manager.But my question is that is there a need to implement locks in the case of single threaded resource manager ?As of understanding message passing model is blocking so it is synchronized.The exact statement from the article is given below

“Locking is supported only by the multithreaded manager because it’s cumbersome to implement in a single-threaded model; the single-threaded manager would need to maintain a priority queue of the clients blocked on the lock. Locking isn’t very useful when there are only a few client applications sharing the interface.”

I think the confusion has to do with two different meanings to the word lock, first a mutex, condvar or other OS device to allow synchronization of threads, or second an external feature provided for a resource, in this case i2c. Let me go through a scenario in both a single and multi-threaded manager.

Client sends a request to lock the i2c. Manager records that this client owns i2c and replies. 2nd Client sends a request to lock the i2c. This client thread finds the device already locked and so it waits using a mutex or condvar. First client sends a message unlocking the device. The 2nd client’s thread wakes up, records that the 2nd clients owns the i2c and replies.

Clients sends a request to lock the i2c. Manager records that this client owns i2c and replies. 2nd client sends a request to lock the i2c. Now the manager must records this client is waiting, and suspend it by not replying. It must remember that this and any other clients are waiting, probably on a queue. First client sends a message unlocking the i2c, which is replied to. Now the manager must look at its queue and reply to the next client.

The alternative for the single threaded manager is to not implement locks. This way, it completes the processing for a client before replying to its message each time.

Thanks for the explanation.From your explanation what i understand is that the locks are implemented in single threaded manager for servicing threads in FIFO manner.Is my understanding right?Lets say 2 threads are blocked (lets say both thread used messagesend()) ,on what basis the thread is chosen to wake up?In the case of single threaded manager is it necessary to implement queue? why can’t there be no queue like multi threaded manager since OS records clients who are waiting on particular locks.

I’ll try to answer, but your question is hard to understand. If two threads do a messagesend() to a single threaded resource manager, in most cases, one will get there first. Since the one that gets there first was running, and is not blocked, and since the resource manager is now at the priority of the sending thread, it will start running. So how would the 2nd client thread get a message off? Well there are a few ways, 1) multiprocessor, 2) round robin reschedule, 3) partition scheduler limitation. I think a astute question would be what if there are three clients sending messages, with two waiting. Which one gets received first. QNX 4 had an option to sort by priority, but I think this was eliminated in QNX 6 with the idea that if you are concerned, use a multi-threaded resource manager. I don’t know this for sure however.

U got my question in fact.Sorry i did not put it in a proper way.I assumed that one thread is being serviced and two threads are blocked but i did not put this info explicitly in my above post.