|
Boost : |
From: Swatosh, Joe R NWP (Joe.R.Swatosh_at_[hidden])
Date: 2002-03-18 21:32:50
> -----Original Message-----
> From: danl_miller [mailto:danl_miller_at_[hidden]]
...
> substantially absent in MT topics in Boost. I hope that I & others
> can correct that absence, because embedded real-time systems have been
> a community using MT (i.e., threads in a shared address-space) for a
> long time. The UNIX interprocess concurrency (in the days/paradigm
> before multiple threads per process) must live with
> separate-address-space limitations (or shared memory limitations)
> which can cramp certain MT-architectures' style. The real-time
> community has been working with multiple threads in a shared
> address-space for over 2 decades. Thus a large industrial body of
> shared-address-space MT "existing practice" regarding multithread
> applications is in the world real-time embedded systems. We must not
> ignore or sideline that large body of "existing practice". If an MT
> concurrency library (e.g., Boost.Threads) can successfully be the
> solution-space for the entire real-time MT problem-space, then that MT
> library fulfills its core mission on which greater & greater
> abstraction can be built. If an MT concurrency library cannot be the
> solution-space for the entire real-time MT problem-space (e.g., due to
> lack of expressivity/features or lack of efficiency), then that MT
> library fails a nontrivial portion of its core mission of modeling the
> best portions of "existing practice". For the C++0x standard to not
> address the real-time MT space would be sad missed opportunity.
>
Can you share references (print or web) to these existing practices?
Thanks,
Joe Swatosh | mailto:Joe.R.Swatosh_at_[hidden]
nLink contract employee | mailto:jswatosh_at_[hidden]
US Army Corps of Engineers | Northwestern Division, Portland District
CENWP-HDC-P | Hydroelectric Design Center
220 NW 8th Ave | v:(503) 808-4032
Portland, OR 97209 | f:(503) 808-4029
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk