Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #68502 > unrolled thread

sht static guard locks

Back to article view | Back to comp.lang.c

Contents

  sht static guard locks fir <profesor.fir@gmail.com> - 2015-08-27 11:11 -0700
    Re: sht static guard locks jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-27 23:15 +0200
      Re: sht static guard locks Ian Collins <ian-news@hotmail.com> - 2015-08-28 09:51 +1200
        Re: sht static guard locks Les Cargill <lcargill99@comcast.com> - 2015-08-27 18:06 -0500
          Re: sht static guard locks David Brown <david.brown@hesbynett.no> - 2015-08-28 10:14 +0200
            Re: sht static guard locks Les Cargill <lcargill99@comcast.com> - 2015-08-28 21:30 -0500
              Re: sht static guard locks fir <profesor.fir@gmail.com> - 2015-08-29 00:46 -0700
                Re: sht static guard locks fir <profesor.fir@gmail.com> - 2015-08-29 01:39 -0700
                  Re: sht static guard locks fir <profesor.fir@gmail.com> - 2015-08-29 03:09 -0700
                  Re: sht static guard locks David Brown <david.brown@hesbynett.no> - 2015-08-29 12:43 +0200
                Re: sht static guard locks fir <profesor.fir@gmail.com> - 2015-08-29 03:20 -0700
                Re: sht static guard locks fir <profesor.fir@gmail.com> - 2015-08-29 04:28 -0700
              Re: sht static guard locks David Brown <david.brown@hesbynett.no> - 2015-08-29 12:38 +0200
      Re: sht static guard locks Ian Collins <ian-news@hotmail.com> - 2015-08-28 11:02 +1200
        Re: sht static guard locks Gareth Owen <gwowen@gmail.com> - 2015-08-31 18:15 +0100

#68502 — sht static guard locks

Im not sure if this is a problem of c++
only or it appleies to c, too

Sometimes (usually?) when using static entities 
in functions the compiler puts special code which
contains a lock acquire and release

Thisd bloats the executable yet also slows down the code.. Im not quite sure 
1)how serious this problem is?
2) in which cases it do apply?
3) how to avoid it in most easy way?
4) how to be sure my app do not contains such sh*t?

[toc] | [next] | [standalone]

#68519

Le 27/08/2015 20:11, fir a écrit :
> Im not sure if this is a problem of c++
> only or it appleies to c, too
>
> Sometimes (usually?) when using static entities
> in functions the compiler puts special code which
> contains a lock acquire and release
>

This is because C++ changed yet again the language underneath your feet.

> Thisd bloats the executable yet also slows down the code.. Im not quite sure
> 1)how serious this problem is?

If you do not care about performance (as many C++ people do) it doesn't 
matter. If you are very interested in performance this is a serious problem.

> 2) in which cases it do apply?

in ALL cases where you have the bad idea to compile your code as C++ 
instead of compiling it as C, where you wouldn't have any of those problems.

> 3) how to avoid it in most easy way?

Call the C compiler and not the C++ compiler for performance critical 
code. Or switch entirely to C. You are writing it mostly in assembler 
anyway, I do not understand why do you use C++!!

> 4) how to be sure my app do not contains such sh*t?
>

By using the C compiler instead of the C++ compiler

[toc] | [prev] | [next] | [standalone]

#68524

jacobnavia wrote:
> Le 27/08/2015 20:11, fir a écrit :
>> Im not sure if this is a problem of c++
>> only or it appleies to c, too
>>
>> Sometimes (usually?) when using static entities
>> in functions the compiler puts special code which
>> contains a lock acquire and release
>>
>
> This is because C++ changed yet again the language underneath your feet.

That's right, a well publicised change was introduced to make static 
variables thread safe.

>> Thisd bloats the executable yet also slows down the code.. Im not quite sure
>> 1)how serious this problem is?
>
> If you do not care about performance (as many C++ people do) it doesn't
> matter. If you are very interested in performance this is a serious problem.

It depends on whether you want speed or correct behaviour with multiple 
threads.  Static variables and threads are a bad combination.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#68533

Ian Collins wrote:
<snip>

 > Static variables and threads are a bad combination.

Oh, not at all. Not at all. It's eminently manageable, up
to and including using sempahores or something beefier.

I can symnpathize with not wanting to deal with serialization issues, 
but it's really something we should all understand well.

<snip>

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#68552

On 28/08/15 01:06, Les Cargill wrote:
> Ian Collins wrote:
> <snip>
> 
>> Static variables and threads are a bad combination.
> 
> Oh, not at all. Not at all. It's eminently manageable, up
> to and including using sempahores or something beefier.
> 
> I can symnpathize with not wanting to deal with serialization issues,
> but it's really something we should all understand well.
> 
> <snip>
> 

This is simply a case of C++ doing automatically that which must be done
manually in C (if you are trying to get the same behaviour).

In C++, the basic principle is that an class constructor will put an
object into a consistent state satisfying whatever invariants you want
for that class.  Other methods may manipulate the object, but they can
assume a consistent state and must end with a consistent state.  For
this to work, it is vital that an object's constructor is called before
it is used, and it is run to completion before anything else is done to
that object.

For "normal" local objects, or heap-allocated objects, that's fine - the
constructor is called when the function is run.  You use whatever
thread-safe techniques you want (such as keeping everything
single-threaded, using thread locals, using locks, or simply "knowing"
that there will be no conflicts).

For file-scope and global objects, constructors are run before main() is
called - thus they run before other threads can be started, and
everything is thread-safe.

For constant initialisation - they only type allowed for statics in C -
there is also no problem.  These are generally initialised by a simple
copying before main() is called.

The problem occurs when you have a function-local static object with a
non-trivial constructor.  Logically, the constructor must be run /after/
all the global and file-scope constructors, but /before/ the rest of the
code in the local function is run.  The local static constructors are
therefore run the first time their code path is executed.  (Conceivably
other rules could have been made, such as running them after the global
constructors but before main() - the decision was made long ago for a
sort of just-in-time execution of local static constructors.)  So local
statics were done a bit like this (in C style) :

void foo(void) {
	static A obj;
	static bool objNeedsConstructor = true;

	if (objNeedsConstructor) {
		A_constructor(&obj);
		objNeedsConstructor = false;
	}
	...
}

That's fine - until you have multiple threads.  What happens if foo() is
called simultaneously from two threads, before "obj" is constructed?
You've got a hideous race condition - applying Murphy's law, every test
you do will pass fine, but you'll get a weird and unrepeatable error
once it is deployed in a critical system.  In C style, you do this:

void foo(void) {
	static A obj;
	static atomic_flag objNeedsConstructor = true;

	if (objNeedsConstructor) {
		getLock();
		if (objNeedsConstructor) {
			A_constructor(&obj);
			objNeedsConstructor = false;
		}
		releaseLock();
	}
	...
}

(And of course you must make sure methods of the class are thread-safe
if needed, just like you always do in multi-threaded programs.)


The C++ committee decided that the above code was messy, easily
forgotten, and hard to get right.  It is especially difficult in C++
where the declaration and allocation of the object is combined with the
constructor (there is no separate call, as shown above).

So with an emphasis on helping people write /correct/ code, it was
decided that the whole mess above could be written:

void foo(void) {
	static A obj;
	...
}

Clear, simple, and reliable.

The cost is that there will be locking, even if there is no possibility
for the race condition to occur in the program.

But consider this:

1. The locks used are extremely fast (typically only a few instructions,
without any function calls) when there is no conflict.  That of course
will depend somewhat on the OS in question.

2. It only applies to function-local statics.

3. It only applies when there are non-trivial, non-constant constructors.

4. It can usually be disabled by compiler switches if you know you do
not need this (but the default is to be safe).

5. It does not apply to thread-local static variables.

6. You can always do things manually, such as by making the object's
constructor trivial and giving it an explicit "init" method.  You can
also often (usually) make the objects file-scope static.

7. If the compiler can figure out that everything is safe, it may
eliminate the locks.  Link-time optimisation may give it the required
knowledge (as does standard techniques, such as making "foo" file-static).


All in all, in reality it is an extremely low-cost way to eliminate some
hard-to-trace potential bugs, and help people write correct code as
easily as possible.

[toc] | [prev] | [next] | [standalone]

#68611

David Brown wrote:
<snip>
>
> All in all, in reality it is an extremely low-cost way to eliminate some
> hard-to-trace potential bugs, and help people write correct code as
> easily as possible.
>

Dang, David., Nice job.

I think the worst of all possible worlds is one in which you write
correct code and have no idea how that actually came to be.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#68620

W dniu sobota, 29 sierpnia 2015 04:28:27 UTC+2 użytkownik Les Cargill napisał:
> David Brown wrote:
> <snip>
> >
> > All in all, in reality it is an extremely low-cost way to eliminate some
> > hard-to-trace potential bugs, and help people write correct code as
> > easily as possible.
> >
> 
> Dang, David., Nice job.
> 
> I think the worst of all possible worlds is one in which you write
> correct code and have no idea how that actually came to be.
> 
good comment - i forgot such climates
long ago but it was remembering me this - coding by hoping this is maybe right ;C

Anyway OFC this static guard is not bad becouse it makes thise guards BUT it is bad becouse it not makes no-guards(I mean programmer should choose.. some keyword or attribute like 'guarded' could repair the situation)

[toc] | [prev] | [next] | [standalone]

#68622

W dniu sobota, 29 sierpnia 2015 09:47:09 UTC+2 użytkownik fir napisał:
> W dniu sobota, 29 sierpnia 2015 04:28:27 UTC+2 użytkownik Les Cargill napisał:
> > David Brown wrote:
> > <snip>
> > >
> > > All in all, in reality it is an extremely low-cost way to eliminate some
> > > hard-to-trace potential bugs, and help people write correct code as
> > > easily as possible.
> > >
> > 
> > Dang, David., Nice job.
> > 
> > I think the worst of all possible worlds is one in which you write
> > correct code and have no idea how that actually came to be.
> > 
> good comment - i forgot such climates
> long ago but it was remembering me this - coding by hoping this is maybe right ;C
> 
> Anyway OFC this static guard is not bad becouse it makes thise guards BUT it is bad becouse it not makes no-guards(I mean programmer should choose.. some keyword or attribute like 'guarded' could repair the situation)

as to c and those initialised statics

1) the idea that statics could be initialised in some 'deferred' way
seem at least partially good to me

(not to say that idea of free initialisers (such functions called before main) is good of bad
(for me its hard to say)

2) this kind of initialisation with hidden guard variable is imo not quite conformant to explicity spirit of c (seems bad)

[toc] | [prev] | [next] | [standalone]

#68623

W dniu sobota, 29 sierpnia 2015 10:40:11 UTC+2 użytkownik fir napisał:
> W dniu sobota, 29 sierpnia 2015 09:47:09 UTC+2 użytkownik fir napisał:
> > W dniu sobota, 29 sierpnia 2015 04:28:27 UTC+2 użytkownik Les Cargill napisał:
> > > David Brown wrote:
> > > <snip>
> > > >
> > > > All in all, in reality it is an extremely low-cost way to eliminate some
> > > > hard-to-trace potential bugs, and help people write correct code as
> > > > easily as possible.
> > > >
> > > 
> > > Dang, David., Nice job.
> > > 
> > > I think the worst of all possible worlds is one in which you write
> > > correct code and have no idea how that actually came to be.
> > > 
> > good comment - i forgot such climates
> > long ago but it was remembering me this - coding by hoping this is maybe right ;C
> > 
> > Anyway OFC this static guard is not bad becouse it makes thise guards BUT it is bad becouse it not makes no-guards(I mean programmer should choose.. some keyword or attribute like 'guarded' could repair the situation)
> 
> as to c and those initialised statics
> 
> 1) the idea that statics could be initialised in some 'deferred' way
> seem at least partially good to me
> 
> (not to say that idea of free initialisers (such functions called before main) is good of bad
> (for me its hard to say)
> 

besides that that statics dont seem like should be initialised once.
even const not necessary must be initialised once, statics yet less

static are just like local variable but with static storage

its a bit fun that some 'designers'
were probably suggested by the fact 
that "static int x = 1" is 'called' once and they lead it to -> "static int x = f();" instead of take "int x = f()" as a potential source of 'derivative'

not ststic atribute makes this behaviour of initialized once,
it is other 'attribute' (or how to call that), more like 'compile time '
ot 'load time' or 'init time' attributes)

(at least it seems so)




> 2) this kind of initialisation with hidden guard variable is imo not quite conformant to explicity spirit of c (seems bad)

[toc] | [prev] | [next] | [standalone]

#68626

On 29/08/15 10:39, fir wrote:
> W dniu sobota, 29 sierpnia 2015 09:47:09 UTC+2 użytkownik fir
> napisał:
>> W dniu sobota, 29 sierpnia 2015 04:28:27 UTC+2 użytkownik Les
>> Cargill napisał:
>>> David Brown wrote: <snip>
>>>>
>>>> All in all, in reality it is an extremely low-cost way to
>>>> eliminate some hard-to-trace potential bugs, and help people
>>>> write correct code as easily as possible.
>>>>
>>>
>>> Dang, David., Nice job.
>>>
>>> I think the worst of all possible worlds is one in which you
>>> write correct code and have no idea how that actually came to
>>> be.
>>>
>> good comment - i forgot such climates long ago but it was
>> remembering me this - coding by hoping this is maybe right ;C
>>
>> Anyway OFC this static guard is not bad becouse it makes thise
>> guards BUT it is bad becouse it not makes no-guards(I mean
>> programmer should choose.. some keyword or attribute like 'guarded'
>> could repair the situation)
>

People (especially in c.l.c) already complain that C++ is too complicated!

And as I wrote in my earlier posts, there are ways to avoid the guards 
if you want, such as by separating initialisation code from the 
constructor code.

> as to c and those initialised statics
>
> 1) the idea that statics could be initialised in some 'deferred' way
> seem at least partially good to me

Yes, it can be a nice thing - but it can be a bad thing too, as 
something that appears to be a fast function can take longer than 
expected as it is handing the initialisation.  And for /very/ heavily 
used functions, even the check of the "objNeedsConstructor" flag is a cost.

Once you understand what is going on, you can make the choices that suit 
your code - but the default given by C++ is with an emphasis on correct 
code, which is good.

>
> (not to say that idea of free initialisers (such functions called
> before main) is good of bad (for me its hard to say)
>
> 2) this kind of initialisation with hidden guard variable is imo not
> quite conformant to explicity spirit of c (seems bad)
>

The hidden guard variable is not in the spirit of C - and it does not 
exist in C.  It /is/ in the spirit of C++, and that is where it is found.

[toc] | [prev] | [next] | [standalone]

#68624

W dniu sobota, 29 sierpnia 2015 09:47:09 UTC+2 użytkownik fir napisał:
> W dniu sobota, 29 sierpnia 2015 04:28:27 UTC+2 użytkownik Les Cargill napisał:
> > David Brown wrote:
> > <snip>
> > >
> > > All in all, in reality it is an extremely low-cost way to eliminate some
> > > hard-to-trace potential bugs, and help people write correct code as
> > > easily as possible.
> > >
> > 
> > Dang, David., Nice job.
> > 
> > I think the worst of all possible worlds is one in which you write
> > correct code and have no idea how that actually came to be.
> > 
> good comment - i forgot such climates
> long ago but it was remembering me this - coding by hoping this is maybe right ;C
> 
> Anyway OFC this static guard is not bad becouse it makes thise guards BUT it is bad becouse it not makes no-guards(I mean programmer should choose.. some keyword or attribute like 'guarded' could repair the situation)

ps should use words like 'primarely' or 'more' but recent times i write such aproxximate way, this is probably no good but if taken some correctment it is probably mostly ok
(though it depends - harder story)

[toc] | [prev] | [next] | [standalone]

#68627

W dniu sobota, 29 sierpnia 2015 09:47:09 UTC+2 użytkownik fir napisał:
> > 
> good comment - i forgot such climates
> long ago but it was remembering me this - coding by hoping this is maybe right ;C
> 
of 2) dont caring at all...
(it would be two new paradigmates
of proffesional coders supported by
proffesional languages) [irony]

for me if i must 'hope' and even if it is really right (but i can not get prove for it)  it pisses me off
(as i think every suitable c programmer).. this 'hope' spoils so damn much

[toc] | [prev] | [next] | [standalone]

#68625

On 29/08/15 04:30, Les Cargill wrote:
> David Brown wrote:
> <snip>
>>
>> All in all, in reality it is an extremely low-cost way to eliminate some
>> hard-to-trace potential bugs, and help people write correct code as
>> easily as possible.
>>
>
> Dang, David., Nice job.
>
> I think the worst of all possible worlds is one in which you write
> correct code and have no idea how that actually came to be.
>

That would be bad - but still better than writing /incorrect/ code with 
no idea how that came to be!

The C++ committee were trying here to make it as easy as possible to 
write correct code, even if you don't understand all the details of 
multi-threaded programming (and few people do).  It adds a little cost 
that is not always necessary - but it is seldom a noticeable cost.  And 
for experts, there are ways to avoid it.

[toc] | [prev] | [next] | [standalone]

#68532

jacobnavia wrote:
> Le 27/08/2015 20:11, fir a écrit :
>> Im not sure if this is a problem of c++
>> only or it appleies to c, too
>>
>> Sometimes (usually?) when using static entities
>> in functions the compiler puts special code which
>> contains a lock acquire and release
>>
>
> This is because C++ changed yet again the language underneath your feet.
>
>> Thisd bloats the executable yet also slows down the code.. Im not quite sure
>> 1)how serious this problem is?
>
> If you do not care about performance (as many C++ people do) it doesn't
> matter. If you are very interested in performance this is a serious problem.

If you take the trouble to look (but that would spoil a good rant, 
wouldn't it?) you would see that static variable initialisation that is 
legal in C (from a constant) is treated the same in C++ as C.  The 
compiler inserts guards where a race condition could occur.

>> 2) in which cases it do apply?
>
> in ALL cases where you have the bad idea to compile your code as C++
> instead of compiling it as C, where you wouldn't have any of those problems.

If it is seeing guards, the code couldn't be compiled as C.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#68763

Ian Collins <ian-news@hotmail.com> writes:

>> If you do not care about performance (as many C++ people do) it doesn't
>> matter. If you are very interested in performance this is a serious problem.
>
> If you take the trouble to look (but that would spoil a good rant,
> wouldn't it?) you would see that static variable initialisation that
> is legal in C (from a constant) is treated the same in C++ as C.  The
> compiler inserts guards where a race condition could occur.

Tell your facts to shut up.  Jacob has no interest in them.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web