[asio][tr2] rough draft of TR2 proposal
Hello all, I have just uploaded a rough early draft of a TR2 proposal based on asio: <http://sourceforge.net/project/showfiles.php?group_id=122478&package_id=199773&release_id=437813> The contents of the proposal are based on the system error_code version I uploaded to the vault a few weeks back. There are some minor differences however, and I plan to update the code and upload a new version that matches in the near future. Feedback is welcome. Please keep in mind that there's still a lot left to write. In particular, the design discussion is really just a quick aggregation of some existing docs plus some points that I want to expand further. I'd be interested to hear what else people would like to see covered. I know there are opinions on things like how stuff should be arranged into header files, so let's hear them :) Also, does anyone know of (or would like to invent) some standardese for discussing threading issues like thread safety and memory visibility? Cheers, Chris
On 8/7/06, Christopher Kohlhoff <chris@kohlhoff.com> wrote:
...
Also, does anyone know of (or would like to invent) some standardese for discussing threading issues like thread safety and memory visibility?
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. Thanks, --Beman
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
- 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 see this requirement as a means of expressing constraints on a more general concept of execution context. Different implementations of execution context would carry out the post using different strategies e.g. thread pools, new thread per post(), visitation of the execution context by a thread as work arrives (e.g. servicing execution in a shared system thread like the win32 message pump) If the programmer could specify precursor code to execute before any posts are serviced, and also before and after each individual service that would be good. void win32_com_precursor() { CoInitialise(/*params*/); } void logging_precursor() { log("execution start"); } void logging_postcursor() { log("execution stop"); } // setup code // executed before first post() is actioned. io_service.addexecutionprecursor( &win32_com_precursor ); // executed before and after each post() is actioned io_service.addexecutionprecursorpercall( &logging_precursor ); io_service.addexecutionpostcursorpercall( &logging_postcursor ); Such pre/postcursors could be a way of obtaining the memory barrier conditions Chris mentions (i.e. grab a mutex, release a mutex). They could also be expressed as a type, of which an instance must be constructed before execution proceeds. This style would lend itself to a more declarative way constructing execution contexts that might lend itself to a language centred implementation, rather than the above, which imposes a fair amount of boilerplate on the programmer. Not sure what that code would look like. Hope this isn't too wildly off topic Simon
Hi Simon, Simon Meiklejohn <simon.meiklejohn@ipfx.com> wrote:
I see this requirement as a means of expressing constraints on a more general concept of execution context. Different implementations of execution context would carry out the post using different strategies
e.g. thread pools, new thread per post(), visitation of the execution context by a thread as work arrives (e.g. servicing execution in a shared system thread like the win32 message pump)
If the programmer could specify precursor code to execute before any posts are serviced, and also before and after each individual service that would be good.
The latest asio code in CVS includes the ability to hook and customise the dispatching of a handler, pretty much as we discussed during the review. There's a short discussion on it in the design section of the TR2 draft. Cheers, Chris
Hi Chris,
The latest asio code in CVS includes the ability to hook and customise the dispatching of a handler, pretty much as we discussed during the review. There's a short discussion on it in the design section of the TR2 draft.
Hi Chris and Beman, I haven't looked at the CVS code - i'll get onto it soon. I did look at the link to documentation at the top of the thread and i don't see too much about hooking the dispatch in there. I do see that asio supports the CoInitialise case by getting the user to call that function (or whatever they want) before calling io_service.run(). That works fine. I don't mean to re-litigate the asio interface - that subject has had quite the hammering. I'm responding to Beman's request in this thread for input on threading in general. My suggestion, for a more general way to specify precursor actions to peform before calling user code relates more to e.g. thread pool's that manage internally the creation of threads which will then call out into user code when requested by a method analagous to io_service.post(). Cheers Simon
simon meiklejohn <simon <at> simonmeiklejohn.com> writes:
Hi Chris,
The latest asio code in CVS includes the ability to hook and customise the dispatching of a handler, pretty much as we discussed during the review. There's a short discussion on it in the design section of the TR2 draft.
Hi Chris and Beman,
I haven't looked at the CVS code - i'll get onto it soon. I did look at the link to documentation at the top of the thread and i don't see too much about hooking the dispatch in there.
Apologies - now i see the bit in the docs. I'll re-read more thoroughly. Cheers Simon
"Beman Dawes" 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.
Perhaps this may be posted on comp.programming.threads too. /Pavel
On 8/11/06, Pavel Vozenilek <pavel_vozenilek@hotmail.com> wrote:
"Beman Dawes" 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.
Perhaps this may be posted on comp.programming.threads too.
I'm in a time crunch, so won't have time for that before the meeting. Chris' response should help focus me. --Beman
participants (5)
-
Beman Dawes -
Christopher Kohlhoff -
Pavel Vozenilek -
Simon Meiklejohn -
simon meiklejohn