Re: [boost] [thread] A few submissions

Subject: Re: [boost] [thread] A few submissions
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-07-04 16:26:39

>> 1. Once-blocks. This is a flavor of the "once" concept. One can define a
>> block of code that should be executed only once, like that:
>>
>>    void foo()
>>    {
>>      BOOST_LOG_ONCE_BLOCK()
>>      {
>>        puts("Hello, world once!");
>>      }
>>    }
>>
>> The code within the block can access names (e.g. variables) as if it was
>> a usual code block.
>
> I like this construction. What about renaming it BOOST_ONCE?

Like I said, I'm not tied with naming.

> Could you explain how do you ensure that the code is thread safe?

I run the test multiple times on a multi-core machine. Never failed.

>> 2. Lightweight read/write mutex. Basically, I want a portable analogue
>> for pthread_rwlock_t, with minimum dependencies, code size and memory
>> footprint. Naturally, it is compatible with Boost.Thread locks.
>>
>> Why not shared_mutex:
>>
>> * shared_mutex.hpp depends on a lot of other headers. It brings in a
>> great deal of Boost.DateTime, although I don't need the timed methods at
>> all.
>
> I consider the timed functions a must to have.

You can always use shared_mutex. I use timed functions quite rarely.

> What about making it depend on Boost.Chrono instead?

1. It's not accepted.
2. I don't think that switching Boost.DateTime to Boost.Chrono does much 
good in terms of lightness. Remember, one of my goals is to make it 
extremely cheap to include.

>> * It offers more than I ever use. I don't need upgradeability.
>
> pthread_rwlock_t are upgradable.

Is it? Through what functions?

> Is there any constraint to don't make your Lightweight read/write mutex upgradable?

On Windows NT6 SRWLOCK doesn't support upgrades. And I don't know how to 
upgrade pthread_rwlock_t.

>> A few notes up-front. There are extensions in some compilers for TLS
>> support. It offers even better performance and easier to use. Also,
>> C++0x will bring this feature into the language. But:
>> * It is known to have problems with dynamically-loaded modules.
>> * It is not portable. Even when C++0x it out, not all compilers will
>> support it right away.
>> * thread_specific does not require the variable to have a static storage
>> duration.
>
> Stefan Stasser has proposed a stati_thread_specific_ptr (see attached file). What about a static_thread_specific that could be implemented using the C++0x thread_local, when available?

Please, see my up-front notes, I've already answered. :)

>> 5. The strictest_lock metafunction. Given the list of lock types, it
>> selects the one that offers the strictest concurrency guarantees (i.e.
>> shared lock is stricter than no lock at all, exclusive lock is stricter
>> than shared lock). This metafunction can be useful in generic code,
>> where the final lock type must be deduced.
>
> Could you show a usage example?

   typedef shared_lock< shared_mutex > lock1;
   typedef unique_lock< shared_mutex > lock2;
   typedef strictest_lock< lock1, lock2 >::type lock3;
   BOOST_STATIC_ASSERT(is_same< lock2, lock3 >::value);

>> I understand that some of these tools might seem specific to my case,
>> but I think they could be useful in general. If any of these tools is
>> accepted into Boost.Thread, the code is not set in stone - namings and
>> implementation details can be changed, if needed. I can do the code
>> transition, write docs and a few tests, if needed. Just let me know if
>> either of these is of interest and whether I am allowed to do so.
>
> I'm interesteed. Why don't request a mini-review of the proposed features as a Boost.Thread extension?

Well, I don't know how to do it formally. Consider this a request.

> Most of the synchronization features should work as well for interprocess. What about including all the synchronization features in a separated Synchro library?

I don't think that things like once-blocks or rw mutex are relevant to 
Boost.Interprocess. And I don't see the point of creating a new library 
for these things. IMO, they fit just fine in Boost.Thread.