Re: [boost] RFC: Multithreading design constraints

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
Cambridge
CB4 2PA
Tel: [phone]
www.digital-healthcare.com
scleary_at_[hidden]
07/06/2000 13:15
Please respond to boost
 
        To:     boost_at_[hidden]
        cc: 
        Subject:        [boost] RFC: Multithreading design constraints
It's 'atomically' -- I don't know if it's a word or not, but it means 'in 
an
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
atomically).
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.
                 -Steve
------------------------------------------------------------------------
Take your development to new heights. Work with clients like Dell and
pcOrder. Submit your resume to jobs_at_liaison.com. Visit us at
http://click.egroups.com/1/4358/3/_/9351/_/960380289/
------------------------------------------------------------------------
[Non-text portions of this message have been removed]