HYDROGEN: Extensibility (by alaric)
Multiprocessing
In a bare-metal environment, you get a number of CPUs. This number may change with time, if your platform supports hotplugging. However, you can't have blocking operations in the HAL - when you do I/O, you ask a device if it's ready, and get on with something else if it's not; the device can interrupt you when it's ready, or what it has some other asynchronous event, and then you ask it to do some work and it gets on with it in the background. You get an interrupt when it's done.
Whereas on POSIX, you can create and destroy threads. If there's less threads than physical CPUs, then the threads may run in actual parallel, but either way, there's always the scope that they'll be time sliced. I/O is normally blocking - when a read or write is request, the requesting thread is blocked until the I/O is complete. You can create and destroy threads at will.
These are two very different models, but we do our best to reconcile them.
HYDROGEN provides only nonblocking I/O. It provides an asynchronous callback model that might be bare-metal interrupts, or might be POSIX signals, or might be something inbetween. All the device operations that might not be able to proceed immediately simply schedule the operation, and take a subroutine handle to invoke when the operation is done.
On bare metal, the number of physical processes we have available is made available as a set of HYDROGEN virtual CPUs; and all the device drivers manage the internal I/O queues of devices and map interrupts back to HYDROGEN callbacks (but they don't implement their own I/O queues in memory; if the device has no queue space left or is otherwise busy, then the attempt to do I/O is rejected and the application asked to try again later). It's up to the application on top of HYDROGEN to provide scheduling and support for blocking processes, and I/O queues and all that.
On top of POSIX, it's a little more complex. We create a POSIX thread for each virtual HYDROGEN CPU, but how many to create? That's an implementation choice - but the POSIX implementation will let the user configure that or, by default, try and count the CPUs on the underlying platform and create that many. It might be worth creating more in very I/O bound systems. We'll see.
All I/O has to be made non-blocking, however. There's a POSIX asynchronous I/O interface for doing that, but it's not very widely supported, so the alternative is probably to include a central I/O dispatcher thread that sits doing select()s, and has a mechanism to interrupt virtual CPU threads to invoke callbacks.
Wed 15th Jul 2009 11:05 pm 
Subscribe