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

"Uenal Mutlu" wrote
> "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:

Correction:

void f()
{ // requires that object must be locked before calling this func
  assert(!m.IsLocked());
  //...
}

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

.