Re: [boost] [thread] A few submissions

Subject: Re: [boost] [thread] A few submissions
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-07-04 15:35:36

----- Original Message ----- 
From: "Andrey Semashev" <andrey.semashev_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, July 04, 2010 7:15 PM
Subject: [boost] [thread] A few submissions

> 
> Hi,
> 
> I would like to propose the following components for inclusion into 
> Boost.Thread:
> 
> 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?

> Why not call_once:
> 
> * The once-code is defined in-place, which greatly simplifies usage in 
> many cases. One of the main goals of the "once" concept is the dynamic 
> initialization, which involves the variables being initialized. With 
> once-blocks there is no need bind these variables into a functor. 
> Once-blocks are also easier to be used within a macro.
> * The resulting code is much shorter since the thread synchronization 
> code is separated from the once-code. call_once is instantiated with 
> each once-functor, although the synchronization code is the same.
> * The once-flag is smaller on Windows. In fact, unlike call_once, the 
> behavior on Windows is equivalent to POSIX.
> * It has ticket #4225 fixed.

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

 
> 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. What about making it depend on Boost.Chrono instead?

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

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

> 3. Lightweight thread-local storage for small POD values. Allows to 
> store POD values of size up to sizeof(void*) with least possible 
> overhead, memory and performance-vise.
> 
>   thread_specific< int > tls;
> 
> Why not thread_specific_ptr:
> 
> * thread_specific_ptr performance depends on the total number of ptrs 
> within the application as it involves an additional lookup among them on 
> access. thread_local does nothing more than abstracting away the native 
> API for TLS, so it provides better performance.
> * thread_specific_ptr requires to dynamically allocate memory even for 
> tiniest things, like bool or int. This is inconvenient and awkward, 
> especially when memory and exception safety matters.
> 
> <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/boost/log/detail/thread_specific.hpp>
> <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/libs/log/src/thread_specific.cpp>
> 
> 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?

> 4. shared_lock_guard. A light analogue to shared_lock, which allows to 
> generate a more efficient code. Ticket #3567.
>
> As a part of this addition I would like to improve segregation of 
> boost/thread/locks.hpp by extracting every component within it into a 
> separate header in a new "locks" directory.

+1 for the separation. This should help to limit the dependencies.
 
> 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?
 
> 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? 

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

Best,
Vicente