From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-31 09:42:15
>From: "William Kempf" <williamkempf_at_[hidden]>
>>The "runtime" is a part of the abstract machine.
>I think that you use a definition of the term "abstract machine" that I'm
>not familiar with. The runtime library is not part of the abstract machine.
>The abstract machine is an abstract model of a CPU; it executes the runtime
>library (and any other code.)
Well, correct me if I'm wrong, because I'm no expert on this subject, but
bootstrapping the program is a part of the abstract machine, no? In any
event, these details are outside of the scope of user or library code,
dependent on details not standardized.
>> >Any dynamically initialized object with static storage duration will
>> >its initialization expression/constructor executed by the initial
>> >AFAICS. So the initial thread is very much detectable and 'special',
>> >any modifications to the abstract machine.
>>Ahh... but here's the rub. You can't statically initialize a thread
>>identifier. In pthreads you have to call pthread_self() and in Win32 you
>>have to call GetCurrentThread() in order to get the "current" thread
>>identifier, and the minute you do this you're no longer in static storage
>>duration. When such data is initialized follows specific rules (which I
>>know you're familiar with) and these rules do not gaurantee that they'll
>>initialized by the "initial thread", and in fact under both Win32 and
>>you have no gaurantee what thread will initialize such data.
>Static storage duration is not the same as static initialization, and I
>specifically said "dynamically initialized object with static storage
Yes, but the quote continued to say "will have its initialization
expression/constructor executed by the initial thread", which isn't
gauranteed, and so I wasn't sure you were using the terminology correctly.
>You are correct that there is no guarantee that the dynamic intialization
>will occur in the context of the initial thread, but the initialization
>rules do imply a lot. The only scenario where dynamic initialization will
>occur in the context of another thread (that is relevant to our problem) is
>* dynamically initialized static object A creates a thread;
>* the thread accesses an object B in a dynamically loaded library;
>* the translation unit that contains B contains a static, dynamically
initialized object C.
>C is now initialized -- most probably (nothing is guaranteed) -- within the
>context of the other thread.
>This issue will be fun to standardize. ;-)
I don't think that "dynamically loaded libraries" have anything to do with
this. AFAIK, the standard doesn't even mention such things, nor am I aware
of the Win32 documentation or POSIX standard mentioning this. The relevant
part of the standard seems to be 3.6.2/3, which when logically extended to
include multiple threads of execution means that any dynamically initialized
object with static storage duration may be initialized in any thread. This
may be a corner case, but it's a very real one that causes very serious
consequences in this context.
>Give me an implementation that ignores this issue and I'll be happy with
>It'll work in 98% of the cases.
I don't follow you here. The issue only exists if you're attempting to
treat the "initial thread" as something special, which the current design
>>But, again, I don't see this as much of a loss. I strongly feel that it's
>>design error to do this, and if you absolutely must do this you can
>>it in user code any way.
>I'm writing a thread_ref library. I don't have access to user code. ;-)
You don't need access. You simply make "joining" an adopted thread (the
"initial thread" is an adopted thread) undefined behavior. Now user code
can't do this, but user code that relies on a design where the "main thread"
is "joined" can easily employ the "thread_main" simulation.
In fact, for your thread_ref case you *can* go a bit further. As I've
suggested, for "adopted" threads you can employ "wait" semantics instead of
"join" semantics. I don't think there will be any real issues with
differences in semantics here.
>>Why does a thread_ref wrapper need to "join" main?
>Why not? Orthogonality. All threads are equal (adopted threads don't
They don't? Then give me a fully equal adopted thread ;). I managed to do
this but only by restricting what one can do with any thread object created
through the default constructor. We've danced around all of this for quite
some time now, but no alternative solution has been given here, and an
alternative is needed for the "initial thread" because it *IS* an adopted
>> >Given the quality of your current implementation, I very much believe
>> >you can overcome the technical problems. ;-)
>>How. Seriously, show me the error of my ways and I'll gladly change the
>>design here in many ways. If you can safely and completely adopt main,
>>including the ability to "join" it, then I should be able to do the same
>>with EVERY adopted thread and we can open up the design constraints a LOT.
>No, I don't think that you can do the same with every adopted thread.
>why I don't ask for it.
I don't believe that this is true. If you can do it for the "initial
thread" you should be able to do it for any "adopted" thread. But let's
start with just a solution for the "initial thread". Show me how you can do
>> >Besides, I don't ask for an implementation that works all the time. I
>> >for a specification that calls for an implementation that works.
>>I prefer an implementation that leaves as few holes as possible. I guess
>>you and I have different design goals in this regard.
>I don't think so. Our main differences are that
>(1) I think that the current thread design is neither low-level nor
>high-level, meaning that it doesn't let me say
>thread t(adopt_main_thread_please_I_take_the_responsibility); // post: t is
Well, I can't recognize the main thread to do this ;). However, I guess an
explicit request to "fully adopt" a thread would work and could be employed
on the "initial thread". It would be, however, highly dangerous and
wouldn't serve much actual utility. I don't see thread_ref as being able to
use this internally, because it won't be able to distinguish the "initial
thread" from any other "adopted" thread either. Only the user code is going
to be able to do this.
>while at the same time it has more undefined behavior than I'd like.
>(2) While I understand your position on the issues where technical reasons
>with current thread libraries call for an interface that could have been
>different were you designing a C++ standard library from the scratch, I
>think that you can afford to move the line a bit. An 'approximation' to the
>ideal implementation that works in 95% of the cases is good enough, as long
>as it's possible to have a 100% implementation with the appropriate support
>from the runtime.
I definately don't agree with this. It makes usage of the library
impossible, since you can't determine when "undefined behavior" occurs (even
knowing that the 5% occurs when threads are adopted doesn't help the user
since he doesn't know when a thread is adopted). With the stricter
definitions we get "undefined behavior" with Boost.Threads, but a
theoretical library based on Boost.Threads that's added to the language
standard can define the behavior and not break any existing code. Undefined
behavior is only bad when it prevents efficient/effective use, and I don't
think the current design does this.
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk