C
Chris Thomasson
[...]
[...]
IMHO, I think I happen to have a pretty good solution to this particular
"aspect" of C++. I will be adding the rest of the information to my rough
draft of a paper I am currently creating which deals with this exact issue:
http://appcore.home.comcast.net/vzdoc/atomic/static-init/
I will show how to build a complete library, step-by-step, that will be able
to directly address the "multi-threading / C++ statin initialization issue"
by adhering to the following basic logic:
((atomic-op/membar)+(C POD)+(Static-C++ Template)
= { atomic statically initialization of c++ objects'};
The basic algorithm will be added to the paper over the next couple of days.
FWIW, I actually posted a crude working version (e.g, after you apply
correction to pseudo-code) of the reference counting algorithm I developed
over on the Boost developer list; still no real response --
;^(...
However, IMHO at least, they should be happy to implement and test the hell
out of my invention, and possibly see for themselves that it can work out
for well...
The initialization of the static C++ object(s) can, and will be freely, and
concurrently, invoked by multiple threads. The objects will start to freely
flow through; many constructors/destructors will have to orchestrated. Also,
the memory that makes up the objects that own those destructors will have be
meticulous tracked, and the dtor called at 'only when the memory is
"quiescent" '...
^^^^^^
[...]
In addition to the rough draft on static-init, I have provided Boost with a
prototype of a mostly lock-free atomically thread-safe reference counting
algorithm:
http://appcore.home.comcast.net/vzoom/refcount/
Any comments on what I am trying to help Boost out with?
I agree with you that impotents can made, here and there...
;^)
Any thoughts/comments on this stuff at all, anybody??
thank you all for your kind patience...
;^)
I think also that the standard should be more specific about the use of
function statics. i.e.
void function()
{
static T t = expression;
}
If "function" is called simultaneously by 2 threads, expression should be
evaluated exactly once and if the initialization of t is being done by
"thread 1" then "thread 2" should wait until the initialization is
complete.
{
__thread static T t = expression;
}
Here, the "t" initializer is called once per thread.
[...]
IMHO, I think I happen to have a pretty good solution to this particular
"aspect" of C++. I will be adding the rest of the information to my rough
draft of a paper I am currently creating which deals with this exact issue:
http://appcore.home.comcast.net/vzdoc/atomic/static-init/
I will show how to build a complete library, step-by-step, that will be able
to directly address the "multi-threading / C++ statin initialization issue"
by adhering to the following basic logic:
((atomic-op/membar)+(C POD)+(Static-C++ Template)
= { atomic statically initialization of c++ objects'};
The basic algorithm will be added to the paper over the next couple of days.
FWIW, I actually posted a crude working version (e.g, after you apply
correction to pseudo-code) of the reference counting algorithm I developed
over on the Boost developer list; still no real response --
;^(...
However, IMHO at least, they should be happy to implement and test the hell
out of my invention, and possibly see for themselves that it can work out
for well...
This is currently implied by the standard that says the initialization of
t must occur once but that requirement should be clarified in the event of
the standard becoming "thread aware". Plenty of discussion around this
"bug" can be found in the gcc bug list. I believe that since gcc 4.0, it
guarentees this for threaded code. I don't recall any other compiler
(besides gcc) guarenteeing this yet.
The initialization of the static C++ object(s) can, and will be freely, and
concurrently, invoked by multiple threads. The objects will start to freely
flow through; many constructors/destructors will have to orchestrated. Also,
the memory that makes up the objects that own those destructors will have be
meticulous tracked, and the dtor called at 'only when the memory is
"quiescent" '...
^^^^^^
[...]
These comments are just from a cursory look at the boost API. I think
there are some serious deficiencies in this proposed thread API and I'd
like to see some more analysis before it gets committed to the standard.
In addition to the rough draft on static-init, I have provided Boost with a
prototype of a mostly lock-free atomically thread-safe reference counting
algorithm:
http://appcore.home.comcast.net/vzoom/refcount/
Any comments on what I am trying to help Boost out with?
I agree with you that impotents can made, here and there...
;^)
Any thoughts/comments on this stuff at all, anybody??
thank you all for your kind patience...
;^)