Subj : Re: Challenge: Multithreading & Synchronization
To   : comp.programming.threads
From : doug
Date : Wed May 18 2005 05:13 pm


"Uenal Mutlu" <520001085531-0001@t-online.de> wrote in message 
news:d6fmti$mi2$03$1@news.t-online.com...
> "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.
>
>

Mate, i don't think anyone is going to take this seriously.  I think you've 
sunk your chances in this newsgroup.

In the future, I'd advise you to:
- actually respond to people's questions/comments about code, rather than 
just waving your hand around, Jedi-like, and saying 'it's true, it's true'
- admit that you've re-invented the wheel or made a mistake, when you have. 
Rather than jumping up and down and screaming like a child.

This whole thread seems like a childish outburst, an attempt to 'solidify' 
or justify the program you've written.  You're wasting your time - we don't 
care.  Not because we're nasty, but because lots of us do this sort of stuff 
for a living, and you've not convinced us.  You do not listen to 
objections/corrections, and refuse to back up your assertions.
To put it bluntly - it's you that has to convince us, not the other way 
around.  Like I said, we don't care.

Your challenge would be good, and I might even do it myself, *if*:
- I didn't know you were just asking so you can turn around and say 'but 
look, my program already does it!'
- I thought your program was useful beyond the extremely simple programs it 
is designed for (i.e. the example you've given, which doesn't allow for flow 
of control, dynamically generated objects, or collections of objets at the 
same 'rank').
- You answered questions.  Anything I come up with here will be ignored, as 
you have done in the past.  I'll spend my time more wisely, thanks.

By the way, i'm still waiting for your pseudocode implementation of a 
recursive mutex that doesn't use memory barriers on lock() if it already 
owns the semaphore.  I don't think it an be done, but I'm keeping an open 
mind!

Doug

.