Re: using local static variable inside a function
On Oct 1, 4:39 pm, Sam <s...@email-scan.com> wrote:
Christian Freund writes:
I think a compiler that gives new memory to static content in functions=
in
the same process is far from the standard. When you look at it closer, =
the
C++ standard does require that static objects in functions are not
thread-safe, because it tells in which area and how often to store them=
..
I cannot find anything in the current C++ standard that refers to anythin=
g
called a "thread". It falls outside of the scope; as such, as soon as
threads are introduced into the picture, the results are no longer define=
d
by the current standard. Instead, one must consult the documentation of t=
he
particular C++ implementation to learn what the effects of threads are, i=
n
that implementation.
application_pgp-signature_part
< 1KViewDownload
How about, making a flag on the static initializer, and a write lock
that's only used once after the initialization so the initializer hits
the uninitialized flag, sets the write lock, and initializes and frees
the write lock and clears the uninitialized flag, but then a thread
waiting for the write lock because of the uninitialized flag might
want to initialize the function of the initializer otherwise failed,
so maybe there should be a timestamp with function calls and times
since the lock, so other functions can determine whether the lock is
frozen and break it, calling then the extra analyzers of the
verification of the static input record in an error-resistant network.
The idea here is to have first a flag that any caller can read. If
it's set, (or the function pointer can be pointed to after the static
initializer block after the first call), the the function is
initialized. If it's unset, then the caller calls the static
initializer of the function scope because the object isn't
initialized, instead of calling the initializer with the object, for
specialized initializers of functions' static members to not
initialize unused static members (lazy). So anyways, the function
takes the write lock that immediately follows the flag and sets it so
other function wait until the flag is cleared to proceed past that
point in the function. Then, it increments the following write
semaphore, which is only used if at all by other functions with
interest in how many calls to the function have tried to initialize
it. That is an extra step on the initializer. Then the static
variables are set up by the initializer, some of them are loaded at
class definitions, but in Java it is when the method is called.
About the scope blocks, and variable visibility, also there are often
static initializers throughout the function as the procedure demands
them besides in statement blocking, about the difference in the
program before and after the objects are statically initialized.
So, the specialized code path has that there are threading semantics
on the atomic static initialization of the object, because the
compiler automatically generates static initialization semantics via
the language definition and its semantics with regards to the linear
sequence of processing in statement blocks with jumps. Then, the user
might want there to be configurable levels of validation about when
other function families export semantics.
Using local static variables is great because if they're sufficient
then otherwise is waste, barring reclamation frameworks. C++ is great
in that the variables don't have to all be at the beginning of the
function, like traditional C, but then the order of initialization of
variables is pretty clearly specified except for example the design
choices about things like order of intialization in initializers and
so on, it's a feature of the language.
Then, with having more than just the one lock in the locks on the
static initializer and static initializers of nested local blocks,
with the flag, the lock, then the semaphore that is never decremented
unlike regular semaphore semantics but shouldn't hold a reference in
the semaphore table, it's more a simple count, there are various other
considerations of what information the calling function had before it
jumped to the static initializer block proper. The most recent time
written would expand the description of how long the process has been
in the write lock blocking other functions from calling the function,
where then if there were other functions that could initialize the
object and the normal initializer failed for some reason, there could
be a retry with in severely affected places, each variable to be
initialized having its own static initializer block semantics, with
waiting callers not being able to call the function proper but to
check on the status of the static initializer so see where it had set
write locks, in working towards locks that the caller might not want
to block upon, where a lock stops execution until the system calls
back another function released the lock, varying on whether the caller
really needs to call the function or can call parts of it that are
initialized already and not others.
It would of course be preferable to build the extensions into the
semantics of the language to avoid maintenance of static initializer
guards with whatever lock framework is in place, trying to make re-
entrant code safe about its static initializers
class static_initializer; // for this class in scope, mark the lock
static void static_initializer::end // here the writer knows it's done
void example_function(int i)
{
static_initializer; // following objects are protected to be
initialized one at a time
static large_table_of_constants t = new large_table_of_constants;
static_initializer::end; // no more with locked initialization
static const char const* label = "LABEL"; // don't care if this is
threadsafe, it's constant
return t.value(i);
}
Without a lock in the initializer, two functions could call the
example_function at around the same time, where the processor
allocates time just as the first is halfway through and the second
then starts, calling functions on the same object again, which is bad,
could lead to undefined behavior. It might not, the problem is then
there are two new tables and when the function exits the destructor
isn't called,where there is a question how to indicate a lights-out
call so then the function destroys its static variables, static
function destructors. As well, functions might want to generally
reset the variable besides worrying about the static variable, that is
preserved between function calls, in the run-time. That is where, I
wonder when static variables have their destructors called.
Regards,
Ross F.