Defect report from : Alexander Terekhov , IBM
(Please direct followup comments direct to yyyyyyyyyyyyyy@xxxxxxxxxxxxx)
@ page 1065 line 33406-33408 section pthread_key_create -- thread-specific data
key creation comment {7}
Problem:
Defect code : 3. Clarification required
http://groups.google.com/groups?threadm=20020220231643.T86509-100000%40news1.macomnet.ru
("Subject: TSD key reusing issue" thread")
[...]
David Butenhof (yyyyyyyyyyyyyy@xxxxxxxxxx) wrote:
"....
> Of course, a program which wants to destroy a key has to not only ensure
> that no threads will ever try to use that key again, but also that
> any resources associated with those keys are cleaned up too, since
> the pthread_key_t registered destructors won't be run.
Right. And the implementation can't (certainly shouldn't) help, including
clearing TSD values, because that substantially increases the cost of ALL
TSD access (by adding synchronization where none is otherwise needed, and
where the standard definitely did not intend to require synchronization).
>>> SUSv3,
>>> http://www.opengroup.org/onlinepubs/007904975/functions/pthread_key_creat
>>> e.html:
>>>
>>> "Upon key creation, the value NULL shall be associated with the new
>>> key in all active threads. Upon thread creation, the value NULL shall
>>> be associated with all defined keys in the new thread."
>>
>>This is the wording of the standard. The standard "says what it says", and
>>conforming implementations are bound to implement what it says. However
>>ridiculous and unsupportable that might be. That doesn't mean it's RIGHT.
>>Conformance is a good goal. Blind conformance to errors is silly.
>
> This behavior supports what I believe is a common programming pattern. If
> the slot is not null, then a thread has no way to know whether it contains
> a value that it has previously stored there, or whether it is garbage.
Absolutely. But the responsibility for setting the TSD value to NULL can
only belong with the application; because only it can know when the
resources it represents (if any) have been released.
....
>>The standard does say that cleanup is the application's responsibility. I
>
> It also does not say that it's *not* the application's reponsibility. ;)
>
> Readers of the standard cannot afford to assume that their
> responsibilities are limited to that which is explicitly spelled out.
Depends on what's spelled out and how. In this case, it clearly SHOULD BE
(and MUST BE) the application's responsibility, but the standard
incorrectly requires behavior of the implementation that contradicts one of
the most basic architectural intents of TSD. It is, inherently, "thread
private" data that shouldn't require synchronization. The standard as
currently written requires synchronization, and that's an error."
[...]
Alexander Terekhov (yyyyyyyy@xxxxxx) wrote:
"....
And, yes, I would have NO problems with a requirement to
"manually" set TSD values to NULL in ALL threads prior to
key destruction... BUT please spell this out *clearly*
in the STANDARD[2] then!
...."
Action:
Uhmm... Are you going to argue against Butenhof? ;-)
BTW, please note:
33528 The pthread_key_delete( ) function shall delete a thread-specific data
key previously returned by
33529 pthread_key_create( ). The thread-specific data values associated with
key need not be NULL at
33530 the time pthread_key_delete( ) is called. It is the responsibility of the
application to free any
33531 application storage or perform any cleanup actions for data structures
related to the deleted key
33532 or associated thread-specific data in any threads; this cleanup can be
done either before or after
33533 pthread_key_delete( ) is called. Any attempt to use key following the
call to pthread_key_delete( )
33534 results in undefined behavior.
|