Re: [boost] [asio][tr2] rough draft of TR2 proposal

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-08-11 09:45:01

Hi Beman,

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
  function z().

- 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.

Cheers,
Chris