> So you can get an update lock, verify prerequisites for an operation
> (gather all the necessary informatin prior to the first write), then
> upgrade to a write lock and do the operation. (Alternatively, if you
> detect an error, you can just drop the update lock.)
Clearly, you can't allow anyone with a read lock to promote to a
write lock because if two simultaneous promotion attempts are made,
someone will have to lose their read lock (or fail to promote permanently.
However, it is usually better to use a strict read/write
implementation, and forgo the slight increase in parallelism that an
'update' lock might get you in exchange for the increased simplicity. This
means you use a 'write' lock instead of an 'update' lock, or code to use a
'read' lock and release the 'read' lock before getting a 'write' lock. The
former solution is simpler, the latter gives you more parallelism.
The justification for adding 'update' locks would have to be that
you plan to use them a lot, otherwise the complexity isn't justified. And
using lots of 'update' locks just means they'll block each other anyway,
just as 'write' locks would.
DS