Boost logo

Boost :

From: mwa_at_[hidden]
Date: 2000-06-07 08:50:53

Aha! Thanks for helping me with my basic reading skills :-) (sorry! my
excuse is that _every_ day is a long day).

I agree that we should drop Event, unless there is a pressing efficiency
reason on some platforms (i.e. an event can be implemented in such a
fashion as to offer considerable efficiency benefits over a gate).

One thing that noone has mentioned is process/task related issues. You
can, on Win32 for example, implement synchronization primitives that are
fine within process, but will break out-of-process. I am assuming that
all of the semantic guarantees made so far relate to in-process
concurrency (and may, but not necessarily, extend out-of-process). To
what extent do we care about this?

Matthew Adams

Development Manager
Digital Healthcare Ltd
Unit 204
Cambridge Science Park
Milton Road
Tel: +44 (0)1223 437407
07/06/2000 13:15
Please respond to boost
        To:     boost_at_[hidden]
        Subject:        [boost] RFC: Multithreading design constraints
It's 'atomically' -- I don't know if it's a word or not, but it means 'in 
atomic way'.  In my post, Event, Gate, and Condition are very similar.  A
Gate is an Event + an atomic open&shut operation.  A Gate is also a
Condition + the ability to stay open (Conditions may only open&shut
We may just drop Event, since Gate does that and more, but we should keep
Condition because there are matching OS primitives already available on
POSIX systems.
Take your development to new heights. Work with clients like Dell and
pcOrder. Submit your resume to Visit us at
[Non-text portions of this message have been removed]

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