Subj : Re: Lockable objects
To   : comp.programming.threads
From : Uenal Mutlu
Date : Sat May 21 2005 02:33 pm

"doug" wrote
>
> "Uenal Mutlu" wrote in message
> > "Giancarlo Niccolai" wrote
> >> Uenal Mutlu wrote:
> >>
> >> > I'm predicting that in the near future all non-trivial objects the
> >> > programming language offers (esp. C++ & STL) will have
> >> > some built-in synchronization methods for the user, like:
> >> >   Lock()
> >> >   Unlock()
> >> >   TryLock()
> >> >   IsLocked()
> >> >   GetLockCount()
> >> > And most probly the locking will be done by using recursive mutices
> >> > internally.
> >>
> >> Mutulu, are you really serious?
> >> It's on the first page of any threading book!
> >>
> >> if ( IsLocked(X) ) {
> >>         <<<  Here another thread locks X >>>
> >>         // do something believing X is not locked
> >>         // and bang.
> >> }
> >
> > I don't know why you would do this.
> >
> >> That's why no-one ever implemented an IsLocked primitive.
> >
> > Obviously with very good reason.
> >
> >> I am beginning to suspect you are a troll; so, please, are you SERIOUS
> >> about
> >> threading or are you making jokes of us?
> >
> > I don't know what your problem is, I've always been serious.
> > The IsLocked() is only to query whether the mutex is currently locked.
> > It is an information about the state of the mutex.
>
> But what use is that information?  It's 'out of date' as soon as you get it.
> You can't seriously use isLocked anywhere (except diagnostics, but you can't
> even trust those fully).

You said it: diagnostics, and debug.
Esp. in such situations like below:

void f()
{ // requires that object must be locked before calling this func

#ifndef NDEBUG
  assert(!m.IsLocked());
#endif

  //...
}


> > For actual locking one uses the Lock() method.

.