Re: [boost] Abstract Thread library

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-08-08 10:58:35

In message <8mp59b+2h4c_at_[hidden]>, frank.gerlach_at_[hidden] writes
>I worked at two companies who each have their own threading library, 
>comprising 
>-thread creation/destruction
>-thread specific storage
>-mutexes
>-condition variables

This sounds like a fairly standard set, which along with my own and
other's experience suggests that perhaps the place to start is with our
own experience and that of others, ie what we know about concurrent
programming, and try our hand at an agreed set of programming
primitives, before deciding on grand, big-up-front-design, final-
solution type schemes for higher-level programming.

>I think that the pthread lib is a good starting point for the design 
>of such a library, if you look for concepts and don't get irritated 
>by the details (scheduling, priorities, processor binding, recursive 
>mutexes etc.)

Yup. This seems to capture the common set of primitives, each of which
is either directly available or easily emulated on all platforms.

>Some more detailed remarks:
>-Mutexes *cannot* emulate counting semaphores; Mutexes+condition 
>variables can
>
>-Counting Semaphores can be useful to manage a (fixed) pool of 
>resources like a pool of database connections. 

So, counting semaphores should be included in the first round of
primitives? Or perhaps the second round? Also, where should we consider
atomic ops (not spec'd in POSIX), such as increment and decrement, in
the priority list?
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Ltd                   mobile: [phone]
  kevlin_at_[hidden]            fax:    [phone]
____________________________________________________________