Unfortunately given what the code does we can't use mutexes, since they're not interrupt-safe, which I'm not particularly happy about. The queues in question are thread-specific, though, which takes some of the danger out of things. I fully expect to have to do more work than just disabling optimizations to disable reordering to make this function right everywhere. (I know, I know, platform-independent interrupt code is just not doable, but...)
Hmm, I don't think the issue is that mutexes aren't interrupt-safe, I think the issue is that if an interrupt routine is reentered it may already be holding a mutex and therefore self-deadlock. The Solaris attributes(5) manpage says this about Async-Signal-Safe routines (which I believe is what you are trying to do):
Async-Signal-Safe
Async-Signal-Safe refers to particular library rou-
tines that can be safely called from a signal handler.
A thread that is executing an Async-Signal-Safe rou-
tine will not deadlock with itself if interrupted by a
signal. Signals are only a problem for MT-Safe rou-
tines that acquire locks. Signals are disabled when locks are acquired in
Async-Signal-Safe routines. This prevents a signal
handler that might acquire the same lock from being
called.Personally, I'd much prefer to use platform-provided interrupt-safe queueing mechanisms, and we will in those places where it's available. I know it *is* available on VMS, and *isn't* available on OS X and Linux. I'm also very painfully aware of some of the issues that need to be dealt with for processors with internal read and write reordering, which isn't anywhere near fun to deal with. (Well, OK, it is, but I'm weird that way)
What I'd really like is a nice, portable, insqti/remqhi implementation, but barring that (since I'm not going to get it) something as close as possible.
I suggest you disable signals during the queue operations, take out the lock, do the work, drop the lock then reenable signals.
-- Alan Burlison --
