OSDev.org

Hi,

In an OS development tutorial I could read at this address : http://sos.enix.org/en/MainPage, I have learnt that a thread can be waiting in several wait queues. However, I believed that once a thread was put in a wait queue, it had to wait to be popped of this queue to resume execution and possibly be placed in another wait queue.

Could you give further explanation ?

Thanks in advance.

you can design some kind of reference. For simplicity, take this as an example:
There is only one sleep queue, "other queue" are event loops/or trigger that wake up the caller thread.

Ok, thanks.

I have a different solution to multiple-wait events. I have an "OO-interface" that every multiple-waitable function needs to define a few methods for (init, abort, clear, isready) + that it must call a special syscall to wakeup waiting threads. The basic interface uses a signal/wait-for-signal model. This is a queue-less implementation, and the multiple-wait interface is also queue-less. Threads waiting for the object(s) are blocked on wait-for-signal, and are reactivated when one of the objects are "available", and this can even be done from IRQs. Each thread needs to create it's own multiple-wait object. I typically use this to wait for TCP/IP, data from serial ports, wait for keyboard. I also provide a user-level variant of signal/wait-for-signal on top of the multiple-wait interface that can be used to define custom between-thread events in an application.

Right now mutexes does not support multiple-wait neither does the IPC-interface, but I might change this someday.

I use the CSP model, which sounds like what rdos solution is.

All messages are passed synchronously. The client will wait for a response from a server. ('rendezvous' in csp)

In this model, a thread can only wait for one message at a time, and not multiple messages.

A process can have multiple threads (or other solutions) to provide the facility of asynchronous messages.

The queue is now implicit. It does not exist as an object or resource. The clients (thread) acts as the buffer. The kernel acts as a switch board to tell the client that you are able to send a message. putting threads in a waiting state if the 'line is busy'.

cleverer minds than mine have stated that the CSP model is inferior to the Actor model. The actor model is asynchronous, and seems to be the key point to the arguement.

The actor model, Being asynchronous, out-of-order, and unreliable messaging, is said to be fair better for truly distrubuted messaging. Applying these properties to CSP maybe harder and less efficient than starting with them from the start.

The advantage for me was that the CSP model is fair simpler. And i do not fully understand the distrubuted algorithms required. I believe A. Tanenbaum has a book on them which i may have a read of.

Mikey

rdos wrote:I have a different solution to multiple-wait events. I have an "OO-interface" that every multiple-waitable function needs to define a few methods for (init, abort, clear, isready) + that it must call a special syscall to wakeup waiting threads. The basic interface uses a signal/wait-for-signal model. This is a queue-less implementation, and the multiple-wait interface is also queue-less.

I had exactly the same idea, I have similar OO-interface, but I use queues to power it. Queue handling is fully transparent though, from code you call these just like any other internal method. I have a methodcall macro that is clever enough to recognize IPC method names, and expand to a "call" instruction or a "msgsend+msgrecv" duo as required.

I also have a special syscall, but it's not for awaking. It is a shorthand version of device driver's typical get_work()+switch+sendresults infinite loop. The syscall is called method dispatch. This never-returning syscall is the last thing a device driver or service will do in it's init function. Further execution will depend on the contents of the messages it receives.
For example, if a KeyPress message arrives, the onKeyPress method will be called, and it's return value or error code will be sent back to the callee automatically. The caller can wait for this reply message, making the call synchronous, or just don't care (the keyboard IRQ handler, that originated the KeyPress message won't care), making it asynchronous.

This solution supports multiple-wait, as message delivery is atomic and guaranteed, and it does not matter from where and in which order the IPC messages arrive. It will look like every client (callee) has it's own counterpart server thread, but in real there's only one inbox queue processing only one message at a time.