6ce
Subj : Re: Non-strictly-conforming and unspecified versus undefined behavior
To   : comp.programming.threads,comp.std.c
From : David Schwartz
Date : Tue Feb 22 2005 12:22 pm


"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote in message 
news:87wtt0wp4g.fsf@qrnik.zagroda...
> Gianni Mariani <gi2nospam@mariani.ws> writes:
>
>>>>                                                              There are
>>>>definite merits to having objects accessible by only a single thread.
>>> Such as?
>>
>> a) It can be alot faster on some platforms.
>
> Not "a lot", because thread-specific addresses can be implemented
> in terms of thread-specific objects with only one extra indirection.

    On every conceivable platform? He said it "can be alot faster on some 
platforms" and you reply with an optimization that works only on some 
platforms (and often burns a register as well).

>> b) Guarenteed that memory is private to a thread, reduces debugging 
>> issues.
>
> I would suppose it increases debugging issues, when the contents of
> the same object (e.g. examined from the debugger) depend on the thread
> we choose as the context.

    You don't think the debugger would be able to figure this out? Yet you 
assume the debugger could understand your version and calculate the correct 
address? Duh.

>> I want the ability to specify that an object is private to a thread,
>> not ALL objects private to a thread.
>>
>> Please indicate where this causes a problem for you.
>
> The point is not whether this mechanism should be provided at all,
> but what should be the semantics of the concrete __thread keyword.

    Exactly. And the current semantics allow either implementation.

    DS

.

0