Boost logo

Boost :

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,
>-thread creation/destruction
>-thread specific storage
>-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: +44 117 942 2990
  Curbralan Ltd mobile: +44 7801 073 508
  kevlin_at_[hidden] fax: +44 870 052 2289

Boost list run by bdawes at, gregod at, cpdaniel at, john at