Re: [Fwd: C Language Thread API]

[David Butenhof <david.butenhof@xxxxxx>]

Ted Baker wrote:
> Here we go again, with more proliferation of
> similar-but-not-identical standards...  I skimmed through the
> document at the cited URL.  It is so close to POSIX threads that I
> wondered what is the justification for introducing yet another set
> of names.  It seems that the semantics are more loosely specified
> than POSIX threads, so if their objective is to be able to support
> a single API as a layer over other thread implementations then
> this might be of some value.  However, I anticipate that some
> users will not be satisfied with such a feature-poor API, and will
> start demanding more, inevitably recapitulating the history of
> POSIX threads.  For example, I guess it is inevitable that we will
> soon see a "real time" version of this and the proposed C++
> interfaces. --Ted
>   
I have to agree with Ted. Perhaps the weakest part of this 
pseudo-generic wrapper package is that it lacks even an extension 
mechanism to change any semantic attributes of threads before starting 
them; something absolutely critical if any future foray into realtime 
scheduling support might come to be in the cards. Or, for that matter, 
any realistic use of the "portable" C facility on real systems for real 
programs, where extensions to access base thread implementation 
capabilities are going to be needed (e.g., realtime, stack allocation 
control, etc.)

Some APIs like UI threads allow creating suspended threads, setting 
attributes via additional APIs, and then starting it; others, like 
pthreads, tried a more structured approach with attributes objects on 
the create operation (which also has the advantage of being easily 
layered on a base implementation that works the other way, while the 
converse is possible but much messier). This has neither.

Of course the "xtime" thing and thrd_sleep() is just POSIX timespec and 
nanosleep(). Adding a C language facility equivalent to 'struct 
timespec' will, inevitably, end up with a similar but semantically 
unrelated data type that needs to be converted and interpreted in any 
real application, causing pain for innumerable developers for many years 
to come. While I see the motivation that drives messes like this, I 
don't like it.

C can't grow to encompass all of the differences between various 
operating systems to enable 100% portable programs, no matter what. 
Frankly I'd much prefer that C focus on a good, strong, portable memory 
model that would enable fully portable use and creative/useful "abuse" 
(lock-free, wait-free) of the various threading APIs already widely 
deployed and understood. Especially when the "standard" C thread 
interface is so bare-bones and non-extensible that it essentially 
prevents most developers from using it anyway.

The memory model is critical. Having a C runtime threading API isn't, 
unless it's going to allow full portable use of at least most common 
posix and win32 mechanisms and attributes; so that you can actually 
write a useful portable (or at least "mostly portable") threaded 
program. This API, as it stands now, doesn't come close to fitting that 
bill.
> On Mon, Aug 11, 2008 at 09:47:21AM -0700, Nick Stoughton wrote:
>   
> > 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
> >
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >