Re: [boost] Re: Threads: New Win32 Implementation

From: Levente Farkas (lfarkas_at_[hidden])
Date: 2000-09-11 03:19:52

William Kempf wrote:
> It's a good thing that most users won't use it.  If a user absolutely
> must have overlapping locks, he will use it.  As for calling the
> private functions... uhmm... not unless you hack the code.  You don't
> have access to the private functions.  That's the whole point here.

I wrote one's can cheet he can write a lock/unlock function with your
new/delete suggestion.
 
> > > class A
> > > {
> > >    mutex mx;
> > > public:
> > >    void foo()
> > >    {
> > >       mx.lock();
> > >    }
> > >    void bar()
> > >    {
> > >       mx.lock();
> > >    }
> > > };
> > >
> > > A a;
> > > a.foo();
> > > a.bar();  // Foo-barred indeed!
> >
> > class A
> > {
> >   mutex mx;
> > public:
> >   void foo()
> >   {
> >     mutex::lock lock(mx);
> >     bar();
> >   }
> >   void bar()
> >   {
> >     mutex::lock lock(mx);
> >   }
> > };
> >
> > A a;
> > a.foo();
> and a.bar();
> 
> You've gone back to the "right" interface here.  The point is, my
> experience tells me that if you allow both interfaces programmers use
> the unsafe interface when they shouldn't and wind up with the problem
> I illustrated.

I illustrate your above code is not a good example since deadlock can
appear with nonrecursive mutex with your safe implementation.
 
> Recursivity has nothing to do with this.  foo() could have been
> called in one thread and bar() in another to get the same results.

there is no problem with your code either!
 
> > > Maybe deadlock that only rarely occurs.  Likely deadlock that's
> very
> > > difficult to debug and correct.  No, it's apples and oranges and I
> > > simply won't live with the danger.  I think that anyone that's
> done
> > > extensive threaded programming would agree with me.
> >
> > I don't, just see the above simple example.
> 
> Which example?  I'm a little lost here since we've both posted
> several examples.

see your example in this mail as quote.
 
> > BUT THIS IS NOT YOUR PROBLEM!!!
> 
> Yes, it is.  I have to use code written by those programmers.  I have
> to maintain code written by them.  I have to help them figure out why
> they're deadlocking.  Why?  Because they are my colleagues working on
> a large project.  We don't work in a vacuum.

I assume your colleages are smart enough to readthe docs before use any
library, and if they not an expert they smart enough to use the interface
titled by "safe".
 
> > what if I make a subclass of mutex which have a lock and unlock
> function ?
> > do you wanna prevent this too ? you can't (if I can lock and unlock
> somehow)!
> 
> It's already prevented, IMHO.  Firstly, the lock/unlock that exists
> in the mutex is private so you don't have access to them even if you
> subclass.  Secondly, there's not a virtual destructor so subclassing
> is strongly discouraged.  So, reasonable misuse is prevented.  Yes,
> you can still misuse things, but only by bending over backward, which
> is then your problem, not mine.

hmm, I'm not read your code before write it, but if there is a way (create
on the heap) to lock/unlock one can write a separate class which has lock
and unlock. so my question how you can prevent it ? still apply.
 
> > > And it's very much possible here.  Why are you fighting me on that
> > > point?
> >
> > you can't see the above subclass example.
> > just beacuse I'm belive I'm right.
> 
> No, I can't see a subclass example, because you still have no access
> to lock/unlock.

than no subclass just another class.
 
> > the above was not
> > my opinion and I don't vote for this.
> 
> Then I'm very confused.  You posted someone else's opinion?  Well
> then, I disagree with them, not with you.

no my opinion is that even if I agree with the small number of primitves
I think (since heard from more people) that it's be useful (the library
get bigger acceptance) if other platforms primitives will also suported.
(this part of the mail was not about lock and unlock).
 
> > I just simple state the the
> > higher level part of a thread library would have to support all
> (most)
> > platform's primitives if we'd like to be excepted by most people.
> > actualy mutex and cv would be enough for me and monotor, rw-lock
> and a
> > few other at higher level.
> 
> I don't agree.  Most reasonable programmers would not resort to using
> platform specific types exclusively just because our library didn't
> include them.  This is especially true if the library were to someday
> be part of the language standard.

this won't be platform specific anymore, since these classes "primitives"
will implemented on all platform (in my dream). so if someone would like
to use event (where event means that primitives which is a primitiv on 
win32 can us it on linux too (there will be an implementation for event).
 
> > > As for not understanding why you need a mutex for a condition...
> > > that's probably the most obvious thing to grasp after a condition
> is
> > > described.  The atomic operation of unlock/wait/lock is an obvious
> > > advantage over Win32 events.
> >
> > operation on event also atomic.
> 
> On the event, yes.  But that's simply a wait operation, not a
> unlock/wait/lock operation.  Apples to oranges, and anyone that is
> introduced to CVs should see this.

that's th main point, they use it in a different way and they used to use it.
 
> Have to?  I don't think so.  If we do, than why are we stopping
> there?  Why not gates as well?  I'm sure there are numerous other
> synch objects in use else where, so we need to include all of them.

why not ?
 
> No, if they are trivial to implement and don't really gain you
> anything over the other synch objects I don't think they warrant
> consideration.

std::accumulate is hard to implement ? give anything over the other
part of the library ? yes it gives something, that is well written.
with cv and mutex you can write everything as with your semaphore and
atomic_t so why do you give a mutex class too ? since it's easier for
the user to use well written, safe code. eg. read-write lock is very
easy, but eg. objectsapce's read-write lock class has a serious bug
which takes me two days to find. that's what we can save for the users
of the library.
 
 -- Levente
 "The only thing worse than not knowing the truth is
  ruining the bliss of ignorance."