Subj : Re: Challenge: Multithreading & Synchronization
To   : comp.programming.threads
From : Sergei Organov
Date : Wed May 18 2005 09:35 pm

"Uenal Mutlu" <520001085531-0001@t-online.de> writes:

> "Sergei Organov" wrote
> > "Uenal Mutlu" writes:
> > > "Sergei Organov" wrote
> > > > "Uenal Mutlu" writes:
> > > >
> > > > > /* Here's a real-world synchronization challenge for accessing shared
> > > > >data from multiple threads (some call this "thread synchonization"):
> > > > What is the aim of posting the challenge? If it's to illustrate
> > > > how much easier it is to implement inherently broken design using
> > > > recursive locks, then your challenge is indeed an excellent
> > > > example.
> > >
> > > It is a real-world example, ie. the requirement is there. Just find a
> > > solution.
> >
> > Well, you didn't answer. What is the aim? Why should I bother to fix your
> > broken "real-world" design? What is the aim? I.e., why should I or anybody
> > else be interested in fixing it? To teach you programming?
> 
> If you feel it needs to be fixed then just say what part you think should be
> fixed.

I'm afraid it's so broken that it can't be fixed in parts. If you indeed
need something working immediately, create single recursive lock and
lock/unlock it at entry/exit to every function, deliver the application,
and then start to re-design your application ASAP, where ASAP in fact
means "as soon as you actually understand where and why it is flawed."

> What's unclear to you? The aim is to collect multiple solutions to the
> problem.

You see, for me your challenge sounds like this: "For undisclosed
purpose I've created this messy broken skeleton and called it
"real-world synchronization challenge". How do you fix my problem?".
For me it's unclear what "solutions" you are going to collect then.
IMHO, the best solution is to throw it away, sorry.

-- 
Sergei.

.