} }Maybe. I need to let this go through my head. Just because we found }it to be the right idea at Tandem doesn't mean it's the right idea }here. I've never been able to understand the advantages of }conditional variables, which may be my viewpoint, or it may be some }basic lack of understanding. }

This is how I think of it:

Mutexs are a synchronization mechanism optimized such that they have to be acquired and then released by the same process.

Tsleep, conditional variables are a mechanism that is optimized such that it is used for one process to wait for an event posted by another process.

A general purpose semaphore could be used for either one. The current use of lock manager locks with bufs is an example of this.

Mutexs map well into what hardware such as Intel or Sparc can natively support. Any of the other mechanism are likely to be twice as expensive, requiring two low level locked operations per high level locked operation. This isn't always true as read/writer locks can be as cheap as a mutex for the case where there is a single reader or writer. But once again this is the case where the same process is acquiring and releasing the resource without action from another process.

It may well be that Tandem hardware made general purpose semaphores as cheap as mutexs. This could be because there was support for a higher level operation or just a few (or one as in the case of Cray) synchronization registers. In either case software can use general purpose semaphores for everything and not screw with all these hybrids.

Chuck

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message