Subj : Re: Challenge: Multithreading & Synchronization
To   : comp.programming.threads
From : Uenal Mutlu
Date : Wed May 18 2005 06:34 pm

"Sergei Organov" wrote
> "Uenal Mutlu"  writes:
>
> [...]
>
> > class Locker
> > {
> > public:
> >   Locker(mutex& Am) : m(Am) { m.lock();   }
> >   ~Locker()                 { m.unlock(); }
> > private:
> >   mutex& m;
> > };
> >
> > Locker then can be used for both mutex and rmutex.
> > This is because rmutex is derived from mutex.
>
> Do you understand that it's wrong provided the following definitions
> from your challenge hold:
>
> > // non-recursive mutex:
> > class mutex
> > {
> > public:
> >   mutex()               { /*..*/ }
> >   ~mutex()              { /*..*/ }
> >   void lock()           { /*..*/ }
> >   void unlock()         { /*..*/ }
> >   [...]
> > };
> >
> > // recursive mutex:
> > class rmutex : public mutex
> > {
> > public:
> >   rmutex()        { /*..*/ }
> > };
>
> Do you understand that (public) derivation of rmutex from mutex is
> broken OO design in the first place?

Says who? Can you also give the exact reason what is wrong?
Just imagine a flag set in the ctor of rmutex for enabling rmutex
functionality in mutex. Everything clear now?

> Anyway, why do you mix OO-issues that you don't seem to understand well,
> C++ issues that you don't seem to understand well, and threads related
> issues that you don't seem to understand well in a single challenge?

Says who? Give facts, examples, not such nothing-saying empty phrases.

The code is for illustration purposes, to describe the problem; it's just a skelleton,
as is written in the text.
You shall find your own solution for the problem.

.