Kim van der Riet wrote:
I agree - I have been looking at this also and there is much that can be
done with these techniques on the store too.
I'd like to replace our ScopedLocker with a LockPointer, but what to do with
ScopedUnlocker?
E.g. How do we translate this into the new scheme:
void Foo::threadSafe() {
Mutex::ScopedLocker l(lock) {
while (condition()) {
dostuff();
{ Mutex::ScopedUnlocker u(lock); externalFunction(); }
domorestuff();
}
}
The point here is that the initial call to condition(); dostuff() is in a
critical section, and all subsequent calls to domorestuff(); condition();
dostuff() are in a critical section, but externalFunction() is not.
Of course we could simply continue to use ScopedUnlocker with LockPtr, but it
violates the intent of the LockPtr design to drop the lock while a LockPtr
exists. On the other hand I can't think of a neat way to rewrite the loop so we
can have separate LockPtr objects to get the same critical sections. We could
unroll it like this
bool ok;
{
LockPtr<Foo> safe(this);
ok = safe->condition());
safe->dostuff();
}
externalFunction
while (ok) {
LockPtr<Foo> safe(this);
safe->domorestuff();
ok = safe->condition());
}
But that kinda sucks. Is there a better way to refactor such a loop to use
LockPtr?
In Alexandrescu's scheme the existence of a LockPointer implies the object is
locked, so I don't see an elegant
