Boost logo

Boost :

From: Alan Griffiths (boost_at_[hidden])
Date: 2000-08-10 15:19:47

In message <20000810190259.2715.qmail_at_[hidden]>, Dietmar
Kuehl <dietmar_kuehl_at_[hidden]> writes
>My understanding is that Greg says we don't need the primitives at all!
>Monitors are sufficient and the better tool: The primitives are error
>prone but people will use them if they are there. Thus, we should drop
>them in favour of the better tool improving overall code quality. I
>think this is a reasonable approach!

Given that the 'primitives' differ in detail between platforms this seem
a good approach - but I don't think monitors are sufficient (they are
new to me and seem like a useful tool)...

  o Another 'high level' concept that has been mentioned is 'atomic
    counter' (which can be implemented using atomic ops where these

  o Do monitors really support the read/write locking idioms adequately,
    or is there another tool needed here?

>Towards this goal, it might be necessary to think deeper about the
>"correct" interface to monitors. It also requires that we document how
>to use this tool, in particular demonstrating how to use the tool to
>solve problems people tend to use the primitives for.

Important, because on any given platform the native primitives will

There seem to be two approaches developing...

The 'high road' design option is to aim for:

 1) Tools sufficiently 'higher level' than the native primitives so that
    they can be implemented efficiently on different native API, and

 2) directly support 'good' threading techniques.

The 'low road' is to identify the sufficient subset of functional
requirements to abstract the primitive operations.

Whatever approach is adopted (the above are not mutually exclusive or
exhaustive) one cannot expect to provide all the functionality that
exists within any given native API. (Iterators don't support all the
functionality of the pointers that inspired them.)

Alan Griffiths  (alan_at_[hidden])
ACCU Chairman   (chair_at_[hidden])   

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