A few general comments. Semaphores are one of the truly evil inventions of computer science. Hard to implement, hard to use. Prone to all kinds of errors.
However, having said that, if you want Unix compatibility, you need them.
For other kinds of code, domains are enough like monitors to be useful for mutual exclusion. Compare and swap, in its generalized form, avoids many of the pitfalls of semaphores.
Some of the specific problems with semaphores in eros-like environments:
(1) Releasing them for failed processes/threads. This problem can be
avoided if you adopt the strategy of failing all the users of a semaphore
when any one fails. However, you still need a mechanism to find out if a
failed domain holds a semaphore. I think this is best handled by the Unix
environment implementation, limiting semaphores to programs which run under
it.
(2) Priority mashing when a low priority process holds a semaphore a high
priority process wants. You seem to want to handle this case. There are,
of course, similar problems with the monitor aspect of domains.
Generalized compare and swap avoids the need entirely.
(3) Ensuring correctness of code which uses them. If they are limited to
the Unix environment, then you have at least reduced this problem to a
previously unsolved problem (correctness in Unix).
Regards - Bill
Bill Frantz | The CDA means | Periwinkle -- Computer Consulting
(408)356-8506 | lost jobs and | 16345 Englewood Ave.
frantz@netcom.com | dead teenagers | Los Gatos, CA 95032, USA