Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
2466 Discussions

Allow for C++11 move semantics in TBB mutex and lock types

Jaak_Ristioja__Cyber
627 Views
Please make tbb::queuing_mutex and tbb::queuing_rw_mutex non-movable in C++11 and later to meet C++11 requirements for STL mutexes (§30.4.1). Mutex implementations outside the STL are not required to meet the requirements for the STL, but this is probably what the developers would expect. In addition, if possible, please also implement move constructors and move assignment operators for the respective scoped_lock inner classes. The std::lock_guard and std::unique_lock classes have this functionality. If this is not possible, please delete these methods. Thanks!
0 Kudos
2 Replies
RafSchietekat
Valued Contributor III
627 Views

Are you saying that your compiler generates an implicit move constructor and/or assignment operator even though, unless you define TBB_DEPRECATED_MUTEX_COPYING (only has an effect for the mutex types, not for the scoped_lock types), TBB provides explicit copy declarations (though not definitions, i.e., the pre-C++11 solution to get "= delete")? I think that would be a bug in your compiler...

I don't see any move features for std::lock_guard, and they should not be implicitly generated for the same reason, unless there's a bug in your C++11 library. There's no reason for TBB's scoped_lock classes to provide them, either.

I do see move features for std::unique_lock. You should be able to use that, but it seems that TBB's queuing mutexes are not BasicLockable like other mutex types are (see "C++11 Compatibility" in the Reference Manual: those TBB mutex types are even Lockable), although a reason is currently not provided nor does one immediately occur to me (I have not investigated further)?

Disclaimer: I don't have the official standard text for C++11.

0 Kudos
Jaak_Ristioja__Cyber
627 Views
Maybe you're right in that the move constructor does not have to be explicitly deleted. I'm not entirely sure whether a move constructor is implicitly defined for these classes. The different interfaces of the STD and TBB locking primitives has been an obstacle. I've written wrappers for the TBB mutex/lock types to make them a bit more similar to the STD ones. I guess that I'm currently trying to work around the issue of tbb::queuing_mutex::scoped_lock and tbb::queuing_rw_mutex::scoped_lock not being movable, whereas std::unique_lock is movable.
0 Kudos
Reply