Hi Beman, Beman Dawes <bdawes@acm.org> 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