From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-08-11 09:45:01
Beman Dawes <bdawes_at_[hidden]> wrote:
> There is going to be an informal meeting of C++ committee
> members and threading experts in Redmond, Washington, US,
> August 23-25 for the sole purpose of making some progress on
> language changes needed to support threading. It would be
> helpful to me if Chris and other Boosters could get together a
> list before then of the minimal core language definitions,
> changes, and other specifications that library developers need
> to specify reliable libraries in a multi-threaded environment.
> What is needed isn't a laundry list of wishes and dreams, but
> a very minimalist list of hard-core needs.
Ok, to start things off, here is a high-level list of what I
think is required for asio. I don't think there's anything
particularly unusual in this list.
- I need some language to discuss thread safety. Examples:
distinct objects of type X can be used concurrently from
different threads; member functions of a value x of type X
cannot be called concurrently; member functions of a value y
of type Y may be called concurrently, except for the member
- I need some language to talk about threads and their call
stacks. Example: a handler object scheduled for execution
using io_service.post() will only be invoked from a thread
that is currently inside a call to io_service.run().
- I need to be able to specify that a library implementation
must include memory barriers at various points in the
execution sequence. This includes specifying the type of the
memory barrier. As an example, prior to the io_service
invoking a handler function there must be an acquire memory
barrier, after calling the handler it will have a release
memory barrier, and a call to io_service.post() will include a
release memory barrier.
- There needs to be some support (whether explicit or implicit)
for guaranteeing that a compiler does not reorder operations
around the functions that include the memory barriers.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk