Re: [boost] mutex feature diagram

From: jsiek_at_[hidden]
Date: 2000-08-26 09:14:47

Remember that the feature diagram is not a statement about what we
will implement, but just a description of the space of possibilities.

I suppose now is a good time to move on to the next stage for mutex,
and start to address your concern about what will be implemented. Here
are some of the questions that will need answering in this next stage.

1. What platforms (OS/compiler/thread facility/version) do we care about?
  - pthreads on Linux/Compaq True64/IRIX/HPUX/AIX/BSD/MacOS X
  - Win32 threads on Windows 98/NT/2000
  - MacOS 8 and 9
  - solaris threads on Solaris 6 and higher (or maybe just use
     pthreads here)
  ... (everyone speak up if there is a platform you care about)

2. What features in the diagram are "portable", which are not.
   - The owner priority options "ceiling" and "inherited" are not
     available in older versions of pthreads, I'll have to look into 
     the exact status here.

3. What features in the diagram do we care about?

We should create several tables that summarize for us the answers to
these questions. Researching the answers, especially for 2., may take
some time. The more detailed and explicit our answers the better.

Cheers,

Jeremy

Milutin Jovanovic writes:
 > 
 > Hi all,
 > 
 > I have been pondering about portability of whatever multithreading support we
 > will come up with. In particular, the mutex feature diagram. The point I am
 > worried about is the amount of optional features that are present in the
 > diagram. My basic question, what is the purpose of us creating a reliable
 > library if the user cannot rely on a particular function being provided.
 > However, there is an argument against as well. Yes, some people might need a
 > more specialised functions. So we should probably not eliminate them
 > alltogether.
 > 
 > My point is, we should first concentrate on a minimalist diagram, set of
 > features that every platform must support. This diagram should provide basic
 > support that is enough to allow portable multi threaded code to be written.
 > Only then shold we look into how to expand this set.
 > 
 > The reason for this is that I would infinitely prefer to have a well defined
 > set of features that are guaranteed to be available everywhere, and design and
 > code around them, completely ignoring optional features. Yes I realise this
 > would be a severely limited set, but it should still be sufficient for vast
 > majority of MT problems.
 > 
 > Miki Jovanovic.
 > 
 > 
 > 
 > 
 >