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

"Giancarlo Niccolai" wrote
> Uenal Mutlu wrote:
>
> >
> > void f()
> > { // requires that object must be locked before calling this func
> >   assert(!m.IsLocked());
> >   //...
> > }
>
> So you are serious. Ok.
>
> However, got a better one:
>
> void f()
> {
>         lock( &x );
>         // it's locked here.
>         unlock( &x );
> }
>
> IsLocked() suggests that you may call a function with or without a mutex
> locked. A well designed application NEVER calls a function while holding a
> mutex, unless very very special cases.

It depends on what type of mutex you use. I'm using recursive mutex
and the following method:
  Any function which modifies an object shall expect that the object be
  already locked by the current thread (or the func itself shall do the
  locking of the object). Modifications must be done only in a locked state
  and of course by the lock owning thread only.

> In a few words, you should NOT call any function between a lock() and an
> unlock(). That because mutexes protect data, and function calls are not
> data to protect.

This limitation is not necessary if a recursive mutex is used.

> If you need to, then you must use a condition wait; they are meant to wait
> for something to relevant to happen, i.e. for the data you want to use to
> be ready.

Using a recursive mutex solves all these problems.

> You are confusing too much the two things, I am afraid.

No, but OTOH you shouldn't overlook your own arrogancy, just
reread your postings to see it.

> Oh, but there aren't condition waits in Windows... sorry...
>
> However, someone created them for you.

Windows has CriticalSection, which is a recursive mutex.
There is also a non-recursive mutex available.
But, this all is not specific to Windows only.

.