> > > You are unnecessarily complicating things and make the program
> > > slower by doing these testings.

> > No, he's in fact making the program faster.

> Are you sure? Let's see:

> void X::f()
> {
>    Lock();
>    for (int i = 0; i < 1000; i++)
>      f();
>    Unlock();
> }

> void X::g()
> {
>   if (!IsLocked())
>     return;
>   //...do..something...
> }

> Are you saying the above version of g() is faster than this one:  ?
> void X::g()
> {
>   //...do..something...
> }

> >>> You are unnecessarily complicating things and make the program
> >>> slower by doing these testings.

> >> No, he's in fact making the program faster.

> > Are you sure? Let's see:

> > void X::f()
> > {
> >   Lock();
> >   for (int i = 0; i < 1000; i++)
> >     f();

> Stack overflow or deadlock here, you probably wanted to call g().

> > void X::g()
> > {
> >  if (!IsLocked())
> >    return;
> >  //...do..something...
> > }

> > Are you saying the above version of g() is faster than this one:  ?
> > void X::g()
> > {
> >  //...do..something...
> > }

> Of course not. Why would you want to test anything if you could just use the
> above? We're talking about recursive mutexes, remember?

>     for (int i = 0; i < 1000; i++)
>     {
>         g();
>     }

>     Unlock();
> }

> void X::g()
> {
>     Lock();

>     //...do..something...

>     Unlock();
> }

> void X::f()
> {
>     Lock();

>     for (int i = 0; i < 1000; i++)
>     {
>         g( false );
>     }

>     Unlock();
> }

> void X::g( bool lock )
> {
>     if( lock ) Lock();

>     //...do..something...

>     if( lock ) Unlock();
> }

> void X::f()
> {
>     Lock();

>     for (int i = 0; i < 1000; i++)
>     {
>         g_unlocked();
>     }

>     Unlock();
> }

> void X::g_unlocked()
> {
>     //...do..something...
> }

> void X::g()
> {
>     Lock();
>     g_unlocked();
>     Unlock();
> }

>> In all the years I've been programming, I have never used a recursive
>> mutex (except in Java, but that's another story).

> Then you must have overlooked their real value.

>> Recursive locking has less dangers than locking without recursive feature.
>> Proof: using recursive locking you never can block or deadlock yourself,
>> but using a locking method without recursive feature you can very easily
>> deadlock
>> yourself.
>> In the latter case even just blocking (ie. waiting for the lock) means
>> deadlock!
>> Don't you see that?

>     Okay, suppose I write a function that supposed to only be called if X is
> not locked. Calling it with X locked is a *bug*. Now suppose I  make a
> mistake -- I am only human. I call the function by mistake with X locked.
> The function goes to lock X itself. I *want* this to break because it
> indicates a *bug*. It is *bad* if this just magically works because then the
> bug will not get discovered.

> void X::f()
> {
>   Lock();
>   for (int i = 0; i < 1000; i++)
>     f();
>   Unlock();
> }

> void X::g()
> {
>  if (!IsLocked())
>    return;
>  //...do..something...
> }

> Are you saying the above version of g() is faster than this one:  ?
> void X::g()
> {
>  //...do..something...
> }

>> >>> You are unnecessarily complicating things and make the program
>> >>> slower by doing these testings.

>> >> No, he's in fact making the program faster.

>> > Are you sure? Let's see:

>> > void X::f()
>> > {
>> >   Lock();
>> >   for (int i = 0; i < 1000; i++)
>> >     f();

>> Stack overflow or deadlock here, you probably wanted to call g().

> :-) Of course g() was meant.

>> >   Unlock();
>> > }

>> > void X::g()
>> > {
>> >  if (!IsLocked())
>> >    return;
>> >  //...do..something...
>> > }

>> > Are you saying the above version of g() is faster than this one:  ?
>> > void X::g()
>> > {
>> >  //...do..something...
>> > }

>> Of course not. Why would you want to test anything if you could just use
>> the
>> above? We're talking about recursive mutexes, remember?

> No I haven't. See below

>> void X::f()
>> {
>>     Lock();

>>     for (int i = 0; i < 1000; i++)
>>     {
>>         g();
>>     }

>>     Unlock();
>> }

>> void X::g()
>> {
>>     Lock();

>>     //...do..something...

>>     Unlock();
>> }

> The above solution works only if your Lock() understands recursive
> locking.
> Otherwise a deadlock will happen.

>> compared to

>> void X::f()
>> {
>>     Lock();

>>     for (int i = 0; i < 1000; i++)
>>     {
>>         g( false );
>>     }

>>     Unlock();
>> }

>> void X::g( bool lock )
>> {
>>     if( lock ) Lock();

>>     //...do..something...

>>     if( lock ) Unlock();
>> }

> I don't like the above because one usually uses a locker
> class like this one to automate the unlocking:

> Locker
> {
>  Locker(mutex& Am) : m(Am)
>   {
>    m.Lock();
>   }
>  ~Locker()
>   {
>     m.Unlock();
>   }
>  private:
>    mutex& m;
> };

> void X::f()
> {
>   Locker(m);
>   for (int i = 0; i < 1000; i++)
>     g();
> }

> void X::g()
> {
>  //...do..something...
> }

>> Let's overlook the fact that the correct version is of course:

>> void X::f()
>> {
>>     Lock();

>>     for (int i = 0; i < 1000; i++)
>>     {
>>         g_unlocked();
>>     }

>>     Unlock();
>> }

>> void X::g_unlocked()
>> {
>>     //...do..something...
>> }

>> void X::g()
>> {
>>     Lock();
>>     g_unlocked();
>>     Unlock();
>> }

> You don't need 2 versions of g() if you use recursive locking.
> The overhead of recursive locking is neglectable because
> it's just incrementing a counter in Lock() and decrementing it in
> Unlock().

>> > "David Schwartz" wrote
>> >> red floyd wrote:

>> >> > May I ask why?

>> >>     There are two possibilities:

>> >>     1) You don't know the mutex is being used recursively. In this
>> >> case, the
>> >> recursive mutex will hide a serious problem.

>> >>     2) You know the mutex is being recursively. In this case, just
>> >> don't
>> >> lock it since you know it's already locked anyway.

>> >>     The problem is that recursive mutexes hide something from you and
>> >> that
>> >> something is extremely important. Consider code like this:

>> >> A) Lock mutex
>> >> B) Unlock mutex
>> >> C) Do something, assuming the mutex is unlocked

>> >>     What happens if the mutex is recursive?

>> > Recursive locks work only for the same (current) thread.

>> I sure hope so.

>> > The code above is IMO wrong, obviously it should be:
>> >  A) Lock mutex