Re: std::call_once without TLS

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

2009/4/30 Chris Fairles:
>> Here's an ABI-compatible patch to fix libstdc++/39909, it would be
>> good if Chris or Benjamin could review it.
>>
>> Code using the new ABI will use a lock object on the caller's stack
>> and provide a pointer to it, if the pointer is NULL then the caller is
>> using the old ABI the global lock object.
>
> Many apologize for being absent on this issue.
>
> This non-ABI breaking patch applies only to 4.4 right?

I don't know. Paolo?
Preserving the ABI will be needed if users want to link objects
compiled using call_once from 4.4.0 and 4.5.0 -- but IMHO trying to
preserve ABI for the experimental C++0x stuff is too difficult and if
someone uses those features they should be prepared to accept that
they can't expect compatibility between major releases.

> Note that archs that want to use the new libstdc++ thread stuff are
> required to implement:
>
> int __gthread_key_create (__gthread_key_t *keyp, void (*dtor) (void *))
> int __gthread_key_delete (__gthread_key_t key)
> void *__gthread_getspecific (__gthread_key_t key)
> int __gthread_setspecific (__gthread_key_t key, const void *ptr)
>
> (see gcc/gthr.h)
>
> Jonathon, if you have a better solution in mind, they are at your disposal.

I'm working on other things that I care about more (<future>,
std::bind, std::result_of ...) so I don't intend to revisit the
non-TLS std::call_once implementation.  My only concern was preventing
valid code from calling std::terminate because of implementation
details in libstdc++, I don't care if it runs slowly on non-TLS
platforms, because I don't use any non-TLS platforms.

> As for trunk, can we still use the abi-breaking fix? I can't recall if
> function's move-assign operator is allowed to throw and even if its
> not, its certainly preferable to hold a global mutex in a
> stack-allocated unique_lock.

The main problem isn't that exceptions might leave the mutex locked
(they could probably be handled with try-catch blocks) but that
concurrent access to a single lock instance are undefined.

My last patch is not very different to the ABI-breaking one, but
manages to support the old ABI and fix it for the new, but if the
decision is made to break the std::call_once ABI for 4.5.0 I'm OK with
that.

Jonathan

Jonathan