Re: [boost] lightweight_once (Was: Boost threadsafe singleton? - Inclusion in Boost)

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-08-26 05:37:17

Andrey Semashev wrote:
> Hello Tobias,
> 
> Friday, August 24, 2007, 4:19:43 AM, you wrote:
> 
>>> Just came across this thread. I had a need of lightweight_call_once in
>>> my Boost.FSM library and implemented it. It is not implemented as an
>>> internal part of the library, but rather as a common tool, like
>>> lightweight_mutex. 
> 
>> Something you'd like to brush up as a Boost X-File ;-)?
> 
>> See
> 
>>      http://article.gmane.org/gmane.comp.lib.boost.devel/162951
> 
> Hmm, I'm not sure of the purpose of this project. Is it supposed to
> pass several tools under its umbrella to boost via fast-track review?

Sort of. It's just an idea, so far.

Its purpose is to avoid lots of fast-track reviews (and reviewing 
overhead) for utility components by grouping them into a "pseudo 
library", thus encouraging developers to brush up / factor out useful 
stuff.

>> The pthreads implementation seems to be using a global Mutex, which is
>> inefficient, because it causes concurrent initializations (that might 
>> have nothing to do with each other) to be queued.
>> To make things worse, that Mutex is initialized with 'pthread_once'.
> 
> Yes, but consider that this code will be executed only once. The rest
> of the execution time this mutex is useless. 

Consider the deadlock if 'once' is used recursively to initialize
different resources...

Further, it's quite unintuitive that a trivial initialization might get
slowed down by one in another thread that takes a lot of time.

> As mutexes may actually
> take some system resources (not sure whether it's true or not on the
> wide variety of platforms out there), having a separate mutex for
> every call_once is a direct waste of them.

You can call 'pthread_mutex_destroy' once you're done with the mutex to
free up eventually acquired system resources.

>> Also, some platforms will not call 'mutex_destroyer' within a dynamic
>> library (you probably know)...
> 
> No, I'm not aware of this. Could you elaborate, please? Which
> platforms are those?

No ctors/dtors are run in static context for shared libraries on most
UNIX platforms.

>> The "trigger" could contain the mutex and the macro for initialization
>> would contain PTHREAD_MUTEX_INITIALIZER, so its creation can be done at
>> compile time by setting up the appropriate bytes in the data segment 
>> (interestingly, you use a similar technique for the "no atomics variant").
> 
> In the "no atomics case" I had no other choice as I needed a mutex to
> safely read the once flag.
> 
>> Other implementations use "while (check) sleep; stuff", which seems 
>> sorta awkward to me. Can't we use "proper" synchronization?
> 
> The fundamental problem arises here - I need to safely create a
> synchronization object. Non-POSIX APIs don't provide things like
> PTHREAD_MUTEX_INITIALIZER or I didn't find them in the docs. 

I see. Would it be an option to use 'yield' instead of 'sleep'?

> And,
> besides that, the aforementioned drawback with waste of resources
> comes up again.

Again, explicit disposal will do the trick.

>> Win32 provides the 'InitOnceExecuteOnce' which seems to do pretty much
>> all we need (it even takes a parameter to get a the state in and 
>> boost::function and a downcast from 'PVOID' will do for the type 
>> erasure). After putting another guard around it (to avoid the dynamic 
>> call and the construction of the boost::function) we're all done.
> 
> InitOnceExecuteOnce is available since Vista and up. I'd like not to
> introduce such constraints on execution platform. Although, there
> could be an alternative implementation for WinAPI, for ones that will
> not execute their apps on XP, for example.

Bummer! Would've been too easy...

>>    I don't know too much about other threading platforms, but I'm sure
>> there are similar means. We could also use a counter for the guard to 
>> use a Semaphore (if it's more handy to do so for some platform) to 
>> notify threads waiting for initialization to complete:
> 
> See my note above. I can't safely create a single semaphore or mutex
> by an API-function call (which was not shown in your code sample). You
> may see my dancing around creating a semaphore in BeOS implementation
> to feel the problem.

I (maybe falsely) assumed that one could obtain one, statically. I'm
aware that "by-call initialization" is problematic (as we'd need 'once',
once again ;-)).

>> For some platforms (such as x86) memory access is atomic, so atomic 
>> operations are just a waste of time for simple read/write operations as
>> the 'is_init' and 'set_called' stuff.
> 
> The point is not only in atomic reads and writes, but in performing
> memory barriers too. Otherwise the result of executing the once
> functor could not have been seen by other CPUs.

Then the memory barriers will suffice for x86, correct? As this code is 
executed on every call, any superfluous bus-locking should be avoided.

Alternatively, doing an "uncertain read" to check whether we might need 
initialization before setting up the read barrier might be close enough 
to optimal.

>> There's some code that throws exceptions with pretty, formatted error 
>> messages: So we're out of resources and execute a whole bunch of code to
>> format an error message... That code might run into the same problem 
>> we're trying to report, so probably throwing something lightweight (such
>> as an enum) is a more appropriate choice (and also gets us rid of some
>> header dependencies).
> 
> Well, you may be right here. I could try to reduce memory allocations
> in error handling.
> But the only possible problem I see there is memory depletion. In such
> case you'll get std::bad_alloc which adheres the declared interface of
> the implementation. So, strictly speaking, if you have enough memory
> you get a detailed error description. If not, you get bad_alloc.

Depending on 'lexical_cast', 'iostream' and 'string' still slightly bugs
me, though.

Another potential issue: It seems Win32 and MacOS variants are currently 
not exception-safe. That is, the initialization routine isn't rerun if 
it has thrown the first time 'once' was called.

Regards,
Tobias