Subject: Re: [boost] [thread] Can Boost.Thread use Boost.Atomic without falling on a compatibility issue?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-01-13 14:15:02
Le 13/01/13 19:41, Andrey Semashev a écrit :
> On Sun, Jan 13, 2013 at 10:32 PM, Vicente J. Botet Escriba
> <vicente.botet_at_[hidden]> wrote:
>> Well, the definition removes the copy constructor and the assignment
>>
>> struct once_flag
>> {
>> BOOST_THREAD_NO_COPYABLE(once_flag)
>>
>>
>> After adding
>>
>> static boost::once_flag once2 = BOOST_ONCE_INIT;
>>
>> to example/once.cpp
>>
>> and I'm seen the following kind of error on a lot of C++11 compilers
> Does this mean that BOOST_ONCE_INIT is not supported and tested with
> C++11 compilers? Seems an oversight to me.
>
>> Maybe it is worth to add a portable extension to the C++11 to ensure
>> compatibility.
> This would be very useful, IMHO, since the same code could be used for
> both C++03 and C++11.
>
>> BTW, couldn't the lock scope be reduced as follows
>>
>> BOOST_THREAD_DECL void commit_once_region(once_flag& flag) BOOST_NOEXCEPT
>> {
>> atomic_type& f = reinterpret_cast< atomic_type& >(flag.storage);
>> { // ++++++++
>> pthread::pthread_mutex_scoped_lock lk(&once_mutex);
>> f.store(initialized, memory_order_release);
>> } // ++++++++
>> BOOST_VERIFY(!pthread_cond_broadcast(&once_cv));
>>
>> }
> No, this is not correct because this would lead to missed
> notifications. Condition variables should always be used under the
> locked mutex.
>
I believed it also but the mutex shouldn't be locked while doing
notifications, only when you change the condition and when you wait for
the condition to be notified.
Best,
Vicente