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

Problems with linking spin_rw_mutex

nypan
Beginner
660 Views
I tried to search for this problem but I failed to find information about it.

My problem is that I for some reason cant link when spin_rw_mutex is used, spin_mutex is fine. But the _rw version just will not work for some reason. I do include the right files and I am compiling with the debug library (the normal library does not work either by the way).

What I am trying to do is a basic scoped lock, i.e.:

spin_mutex test;

// bla bla

{
spin_mutex::scoped_lock lock(test);

// Do something
}

This works fine with the spin_mutex but with the spin_rw_mutex I get that the folowing symbols are undefined:

tbb::spin_rw_mutex_v3::internal_acquire_reader()
tbb::spin_rw_mutex_v3::internal_acquire_writer()

Anyone else had this problem or know why I am getting it? Its incerdably anoying.
0 Kudos
6 Replies
Bartlomiej
New Contributor I
660 Views
The reason seems obvious. For an ordinary (spinning or blocking) mutex you just lock and unlock it.
A rw-mutex can be locked either by a reader or by a writer - it cannot be "simply locked".

So, in the constructor of the scoped lock, you must add another parameter - according to the file spin_rw_mutex.h it is a boolean value indicating if the locking thread is a writer or not.

Regards
0 Kudos
nypan
Beginner
660 Views
Quoting - Bartlomiej
The reason seems obvious. For an ordinary (spinning or blocking) mutex you just lock and unlock it.
A rw-mutex can be locked either by a reader or by a writer - it cannot be "simply locked".

So, in the constructor of the scoped lock, you must add another parameter - according to the file spin_rw_mutex.h it is a boolean value indicating if the locking thread is a writer or not.

Regards

Thank you for the answer. It does now help however because the spin_rw_mutex has a default value (false) specified for the second parameter to the constructor and therefore it should work. But even if I do specify the parameter explicitly I get the same error. Also the error is not a compiler error, its a linker error - a missing parameter to a constructor should result in a compiler error right?
0 Kudos
RafSchietekat
Valued Contributor III
660 Views

You're not likely to get relevant answers without providing at least some details about your setup (O.S., TBB version, ...).

0 Kudos
Bartlomiej
New Contributor I
660 Views
Indeed, I've written you a stupid thing last time.
But again - on my machine such replacement works fine.
Make sure, you changed all spin_mutex to spin_rw_mutex phrases (the best way is to define a type using typedef).
If it's not such a simple error, please write - as Raf said - more details.

Regards

0 Kudos
nypan
Beginner
660 Views
Quoting - Raf Schietekat

You're not likely to get relevant answers without providing at least some details about your setup (O.S., TBB version, ...).


Yeh sorry about that. I am running tbb 2.2 (tbb22_20090809oss) on os x 10.4 with gcc 4.0. This is the latest stable release so it shoud work.
0 Kudos
RafSchietekat
Valued Contributor III
660 Views
They seem to bedeclared in the export files all right (both 32 and 64 bits, which detail you omitted, i.e., src/tbb/mac{32,64}-tbb-export.def). Are you using _src.tgz or _mac.tgz? If the latter, perhaps try the former just to see if it makes a difference (I've never used anything else than _src.tgz myself). What happens if you do a "make all" (I'm guessing that test/test_mutex.cpp would try to use the same code)? Or perhaps you had been using another version before and not everything got replaced when you upgraded (here I'm just guessing), so you might try to clean and reinstall TBB? Otherwise, I'm out of ideas.
0 Kudos
Reply