Nick -
I don't have any strong opinions on the pthreads vs. Dinkumware issue.
However, there are some details in this proposal, that I think should be
adjusted. In particular, the memory visibility discussion needs to be
consistent with whatever the final memory model ends up being. It's important
how this interacts with atomics, which I hope will also be in the standard.
There are other issues, such as with call_once.
I think it's crucial that the standard clearly guarantee sequential consistency
for data-race-free programs (low-level atomics excepted), since I think that's
the only programming rule that I think we can actually explain to most
programmers. And it's the one the one that's now supported by both Java and
the C++ WP.
This model (sequential-consistency for data-race-free programs) effectively
requires that mtx_trylock() and mutex_timedlock() be allowed to spuriously fail
to acquire the lock. Otherwise the client can tell whether mtx_lock() includes
a memory fence on both sides, which makes it significantly more expensive to
implement on many architectures. I think the pthreads specification should
eventually be correspondingly relaxed. (This is not intended to encourage
implementation changes, and hence does not have to break code, even that small
amount of really obscure code that relies on this. But it does cause many
existing implementations to actually meet the letter of their specification.)
This proposal also raises the question of whether mutexes should be statically
initializable. Requiring this may pose some implementation challenges on some
platforms, but I believe statically initialized mutexes are very useful to the
client. The alternative is often an (easily forgotten and rather messy)
call_once call before acquiring a mutex.
Hans
> -----Original Message-----
> From: Nick Stoughton [mailto:nick@xxxxxx]
> Sent: Monday, August 11, 2008 9:47 AM
> To: austin-group-l@xxxxxx
> Subject: [Fwd: C Language Thread API]
>
> The ISO C Committee is intending to add a standardized thread
> API to its next revision. The Austin Group had at one point
> suggested to them that if they did so, pthreads would be the
> obvious one. However, the current proposal is based on the
> Dinkumware thread library, which is a very thin layer over pthreads.
>
> I have an action item to ask the Austin Group for feedback (review and
> comment) on this proposal, which can be found at
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1287.htm
>
> If anyone has any difficulty in accessing this paper, please
> email me and I send it it you independently.
>
> The next C meeting is September 8-12 in Santa Clara.
> --
> Nick Stoughton Cell: 510 388 1413
> USENIX Standards Liaison Fax: 510 548 5738
>
>
|