Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Paavo Helde <eesnimi@osa.pri.ee>
Newsgroups: comp.lang.c++
Subject: Re: Pre-main construction order in modules
Date: Tue, 1 Apr 2025 11:41:01 +0300
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <vsg8qu$2m576$1@dont-email.me>
References: <vsb12i$2mv42$1@dont-email.me> <vsbl21$1jsvi$1@dont-email.me>
 <vsbo2p$1p5ov$1@dont-email.me> <dTdGP.136957$cgs7.71710@fx14.ams4>
 <vsbqc2$1rk0n$1@dont-email.me> <48eGP.730204$J61.500281@fx08.ams4>
 <vsbr65$1sgoe$1@dont-email.me> <YgeGP.136960$cgs7.11888@fx14.ams4>
 <vsdkpe$3r9qf$1@raubtier-asyl.eternal-september.org>
 <vsdlc3$3rhjh$2@dont-email.me>
 <vsdm8c$3sq3u$1@raubtier-asyl.eternal-september.org>
 <vse1lm$8iai$1@dont-email.me>
 <vse1vr$9d9k$1@raubtier-asyl.eternal-september.org>
 <vsfonk$25iou$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 01 Apr 2025 10:41:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d17767faa39812c4e0507ca7620e5c26";
	logging-data="2823398"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+pVv9zRShqMOCMmnQCzVsqmi4Rwb0oudg="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:qm6NV1tNvJyMivfdYhcVjngsbLE=
Content-Language: en-US
In-Reply-To: <vsfonk$25iou$1@dont-email.me>
Bytes: 4050

On 01.04.2025 07:06, Jakob Bohm wrote:
> On 2025-03-31 14:32, Bonita Montero wrote:
>> Am 31.03.2025 um 14:26 schrieb Paavo Helde:
>>
>>> An example of pre-C++11 thread-safe Meyer singleton:
>>>
>>> std::map<std::string, std::string>& GetGlobalMap() {
>>>
>>>      // No dynamic initialization, so this is safe:
>>>      static std::map<std::string, std::string>* pGlobal = NULL;
>>>
>>>      // No dynamic initialization, so this is safe as well:
>>>      static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
>>>
>>>      // Initialize the global static if not yet initialized.
>>>      pthread_mutex_lock(&mutex);
>>>      if (!pGlobal) {
>>>          pGlobal = new std::map<std::string, std::string>();
>>>      }
>>>      pthread_mutex_unlock(&mutex);
>>>      return *pGlobal;
>>> }
>>
>> That's rather slow. Double-checked locking as implemented for
>> all static locals with current runtimes is much more efficient.
> 
> Artificial locking around ALL static locals as implemented by some
> modern compilers is highly wasteful as in most code, the code
> structure already ensures a single thread will be the first to
> execute that initialization/construction, 

The synchronization of static variable initialization (which may or may 
not involve locking) is demanded by the C++11 standard (so it is pretty 
portable) and makes it easier, faster, safer, and more maintainable to 
use statics in multithreaded C++ code (which is "most code" in my area).

In an unlikely event this causes any measurable slowdown in a tight 
loop, a reference to the static variable can often be extracted before 
the loop.

> often one of the threads in the compiler itself.

Sorry, cannot parse that sentence.

> That locking by compilers seem to be the result of someone in the C++ 
> ctte wanting to take over every OS feature that used to be out of
> scope for system programming languages like C/C++.
>  It also makes it
> unnecessarily harder to use the system compiler to implement the lower
> level code that exists at a more fundamental / portable level than
> silly textbook examples .

How comes? In some lower level code you one might just not use dynamic 
initialization of statics, which avoids any need of thread synchronization.

If you do not know the differences between zero-initialization, constant 
initialization and dynamic initialization, then you are not in a 
position to implement any "lower level" code.