On 1.12.11 14:25, Jukka Zitting wrote:
For the current problem I'd rather have the microkernel to expose some
test-and-set semantics as Tom describes in [2].
A test-and-set operation necessarily requires at least some level of
atomicity which can quickly become a bottleneck for a clustered setup.
Yes but that critical section can be very small: since the changes are
written to disk ahead, locking is only required when writing the new
revision id to the journal. With the test and set approach, the only
addition is to do the test inside the lock. With (correct) double
checked locking this can even be further optimized.
Michael
