C++ locking, volatile, Relevant article from Alexandrescu

[Andrew Stitcher <as...@redhat.com>]

Doing some research on the c++ semantics of volatile recently I came
across this rather relevant article again.

I think that there are some important ideas in here that could help us
greatly reduce the chance of race conditions where we're using mutexes
to encapsulate critical sections.

http://www.ddj.com/cpp/184403766

Andrew

Re: C++ locking, volatile, Relevant article from Alexandrescu

[Alan Conway <ac...@redhat.com>]

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

Re: C++ locking, volatile, Relevant article from Alexandrescu

[Kim van der Riet <ki...@redhat.com>]

I agree - I have been looking at this also and there is much that can be
done with these techniques on the store too.

Kim

On Tue, 2008-06-03 at 10:22 -0400, Alan Conway wrote:
> Andrew Stitcher wrote:
> > Doing some research on the c++ semantics of volatile recently I came
> > across this rather relevant article again.
> > 
> > I think that there are some important ideas in here that could help us
> > greatly reduce the chance of race conditions where we're using mutexes
> > to encapsulate critical sections.
> > 
> > http://www.ddj.com/cpp/184403766
> > 
> 
> Agreed, very good article. I've been marking "internal" functions that should 
> only be called with a lock already held by adding a dummy extra Locker& 
> parameter which is ugly and doesn't have as much expressive power.
> 
> Definitely something we should adopt post GA.
> 
> 

Re: C++ locking, volatile, Relevant article from Alexandrescu

[Alan Conway <ac...@redhat.com>]

Andrew Stitcher wrote:
> Doing some research on the c++ semantics of volatile recently I came
> across this rather relevant article again.
> 
> I think that there are some important ideas in here that could help us
> greatly reduce the chance of race conditions where we're using mutexes
> to encapsulate critical sections.
> 
> http://www.ddj.com/cpp/184403766
> 

Agreed, very good article. I've been marking "internal" functions that should 
only be called with a lock already held by adding a dummy extra Locker& 
parameter which is ugly and doesn't have as much expressive power.

Definitely something we should adopt post GA.