RE: multi threading support

From: Matthew Hurd (matthurd_at_[hidden])
Date: 2000-05-31 09:19:49

Hi,

Hmmm, ACE has been doing this stuff for a while.  License is compatible with
Boost but ACE has its own party.  An adoption or factoring exercise could
produce the Boost Distributed Library.

Where do you draw the line?  Virtual synchrony?  Barriers?  DSM?  MPI?  An
ORB aka TAO?

Perhaps the answer is anything that is below OMG.  ACE-like stuff is OK.
ORB's are not.  That is, threads, locks, protocols and associated patterns
are fair game.

matt.

Note:  ACE contains the double-check patterned solution to the Singleton
thread safety question as referenced (in a John Vlissides link) in a
previous post.  Bottom line is Singleton is not too useful without thread
safety.

-----Original Message-----
From: Dietmar Kuehl [mailto:dietmar_kuehl_at_[hidden]]
Sent: Wednesday, 31 May 2000 21:22
To: boost_at_[hidden]
Subject: multi threading support (was: [boost] Hello boosters)

Hi,

here are just some thoughts on the multi threading support to shape
the challenge(s):

--- Beman Dawes <beman_at_[hidden]> wrote:
> In past discussions there has been a lot of concern that a threading
> library needs to be approached very carefully.  There are prior
> theories, practices, and standards that need to be considered.
> Consistent behavior across implementations on different OS's is
> obviously a problem.  It is one thing to wrap some specific OS's
> system calls, and another to specify a set of behavior that can be
> supported on virtually any multi-threaded OS.

I think the important part which is to be supported on virtually any
multi-threaded OS is the access to a basic thread synchronization
mechanism, ie. to a mutex to protect critical sections. With this in
place other components can be implemented with an eye towards thread
safety simply using the mutex and a corresponding lock class which
automatically releases the lock.

The whole issue of thread creation, priority manipulation, termination,
etc. is IMO not that important as is the thread synchronization: To
implement classes suitable for a threaded environment, there is no need
to do this at all. Threads can be created in some non-portable way but
the thread safe classes are supposed to be portable. Of course, it
would also be nice to have a portable interface to this functionality,
too, but I consider the thread synchronization as a more urgent and
basically separate issue. That is, I would probably place favour two
separate challenges, namely one for the synchronization mechanism and
another one, probably taking the results of the synchronization
challenge into account, for other threading mechanisms.

Actually, there might even be a third challenge, namely one for a
guideline what is supposed to be thread protected and what is not and
how components should use thread protection. The need for such a thing
shows up with the numerous requests for "thread safe" containers where
users often expect the container to deal with their threading problems
which will never be the case (see eg.
<http://www.sgi.com/Technology/STL/thread_safety.html> for a discussion
of this issue). For example an expression like 'a[i] = 17' cannot be
thread safe by adding thread support to the class of 'a' unless the
return of 'a[i]' is actually a proxy holding a lock on 'a' which would
be rather inefficient and fairly error prone (due to a large potential
for dead locks). Another part of such a guideline would spell out how
to prevent dead locks.

Regards,
  Dietmar

=====
<mailto:dietmar_kuehl_at_[hidden]>
<http://www.dietmar-kuehl.de/>

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/