Re: [boost] Re: Threads: what I wrote...

From: Lois Goldthwaite (loisg_at_[hidden])
Date: 2000-08-09 06:48:05

One library vendor advertises that its container classes are 'MT-hot,' meaning
that every operation is internally synchronized to make multi-threaded
programming transparent. The problem with this approach is that often you need
to hold a lock over several operations which make up a complete transaction,
which must be executed all or nothing. (Think about transferring money between
several bank accounts -- a single debit without the corresponding credit really
messes things up.) The need to provide transaction-level locking is why some
programmer control is needed.

Even in Java, a function can synchronize on a specific object or on a class, in
addition to the synchronized functions which are more common (they just
synchronize on 'this'). If you're careful, you can reduce the period of time an
object is locked to a few instructions instead of the whole function, to
increase throughput.

Having said that, IMHO a lock object which releases the lock when it goes out
of scope is definitely the superior way to handle this. Java can't use this
approach because it doesn't have proper destructors, but then it doesn't have
lock objects either (the synchronized section of code is put into a { } block).

I would be very wary of allowing mutexes and other synchronization objects to
be copied. The point of the mutex is that it provides a single point of
protection for a single resource. If you make a copy of a mutex that some other
thread has locked, the other thread won't know to release your copy in addition
to the original.

Lois

Dietmar Kuehl wrote:

> Hi,
> --- Milutin Jovanovic <miki_at_[hidden]> wrote:
> > First there are legitimate uses of long locks, so you should not try
> > to stop such usage.
>
> I keep asking for multi threading related idioms but nobody has
> proposed something using long locks. Thus, I'm assuming that they don't
> have any use. This matches the implied threading interface of Java,
> where only functions are synchronized.
>
> However, if there are indeed usage patterns which use long locks, it
> would be rather useful to learn about them. Still, my impression is
> that this would not use public "lock()" methods on the mutex. There
> are other approaches which I consider preferable over using 'catch'
> clauses which I consider extremely error prone.
>
> > Finally, what stops the user from dynamically allocating the
> > 'auto_lock' object?
>
> A private 'operator new()', for example. ... or the lock is returned
> from the 'lock()' method and passed around as long as the lock is to
> be retained. This also addresses the long lock issue. Of course, the
> lock can be embedded in a class created for this specific purpose.
> However, the philosophy of C++ is to work against Murphy, not against
> Machiavelli.
>
> > This is not to say that locks should be used indiscriminately. Proper
> > thread synchronisation takes extreme discipline. My view is however
> > that education is the only way to achieve this.
>
> My view is that it can be made harder to make dump errors: Education
> does not help against dump errors and against me being forgetful. ...
> and if there is no 'lock()' method in the mutex, people will have to
> look at the documentation to find out how to lock it, fostering
> education. If there is a 'lock()' method, guess what is used despite
> the documentation is saying it is a dangerous thing to do! My
> experience is, that the average programmer never reads documentation
> and, even worse, is proud of this. This view is at least partially
> supported by a current thread in comp.lang.c++.moderated.
>
> =====
> <mailto:dietmar_kuehl_at_[hidden]>
> <http://www.dietmar-kuehl.de/>
>
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/
>
>