using queuing_mutex and queuing_rw_mutex

[praveen_satishgmail_]

I am a student..
can any one provide me with examples of queuing_mutex and queuing_rw_mutex in cpp. Can we make a lock wait untill it acquired using queuing_mutex in TBB.If possible provide me semaphore examples in TBB mutual exclusions..

[Bartlomiej]

Quoting - praveen.satishgmail.com

can any one provide me with examples of queuing_mutex and queuing_rw_mutex in cpp.

I'm not sure if I understand you correctly.
The usage of queueing mutexes is identical to usage of other mutexes. Typically you use them, by creating scoped locks in critical sections:

typedef tbb::queueing_mutex Lock;
Lock lock;

{
lock_type::scoped_lock l (lock);
// perform operations in the critical section
}

When leaving the block, variable l will be destroyed and the mutex will be released in its destructor.
You can also call lock.acquire() and lock.release() methods directly, but what for?

The other question is: why use a queueing mutex at all? IMHO, as queueing mutexes have nice theoretical properties, they are rarely useful in practice as other types of mutexes are more efficient and (usually) suffice. It would be interesting to hear if other TBB users do use queueing locks. When and why do you find them necessary?

Can we make a lock wait untill it acquired using queuing_mutex in TBB.

Unless I don't understand you do mean, the answer is: yes, obviously, that's what all locks are for.

If possible provide me semaphore examples in TBB mutual exclusions.

Semaphores are not defined in TBB. You ca nsimply simulate them by an integer variable guarded by a lock, but it would not be very efficient. But that's probably not what you wanted, is it?

[praveen_satishgmail_]

Quoting - Bartlomiej

I'm not sure if I understand you correctly.
The usage of queueing mutexes is identical to usage of other mutexes. Typically you use them, by creating scoped locks in critical sections:

typedef tbb::queueing_mutex Lock;
Lock lock;

{
lock_type::scoped_lock l (lock);
// perform operations in the critical section
}

When leaving the block, variable l will be destroyed and the mutex will be released in its destructor.
You can also call lock.acquire() and lock.release() methods directly, but what for?

The other question is: why use a queueing mutex at all? IMHO, as queueing mutexes have nice theoretical properties, they are rarely useful in practice as other types of mutexes are more efficient and (usually) suffice. It would be interesting to hear if other TBB users do use queueing locks. When and why do you find them necessary?

Can we make a lock wait untill it acquired using queuing_mutex in TBB.

Unless I don't understand you do mean, the answer is: yes, obviously, that's what all locks are for.

If possible provide me semaphore examples in TBB mutual exclusions.

Semaphores are not defined in TBB. You ca nsimply simulate them by an integer variable guarded by a lock, but it would not be very efficient. But that's probably not what you wanted, is it?

[praveen_satishgmail_]

Quoting - Bartlomiej

I'm not sure if I understand you correctly.
The usage of queueing mutexes is identical to usage of other mutexes. Typically you use them, by creating scoped locks in critical sections:

typedef tbb::queueing_mutex Lock;
Lock lock;

{
lock_type::scoped_lock l (lock);
// perform operations in the critical section
}

When leaving the block, variable l will be destroyed and the mutex will be released in its destructor.
You can also call lock.acquire() and lock.release() methods directly, but what for?

The other question is: why use a queueing mutex at all? IMHO, as queueing mutexes have nice theoretical properties, they are rarely useful in practice as other types of mutexes are more efficient and (usually) suffice. It would be interesting to hear if other TBB users do use queueing locks. When and why do you find them necessary?

Can we make a lock wait untill it acquired using queuing_mutex in TBB.

Unless I don't understand you do mean, the answer is: yes, obviously, that's what all locks are for.

If possible provide me semaphore examples in TBB mutual exclusions.

Semaphores are not defined in TBB. You ca nsimply simulate them by an integer variable guarded by a lock, but it would not be very efficient. But that's probably not what you wanted, is it?

thanks for your answer... I need to implement MONITORS as a [.h] file. i m really out of ideas that what i have to do. i hav studied in ART OF MULTIPROCESSOR PROGRAMMING that monitors are the union of queuing_mutex and semaphores and other mutexs.

In order to know about those mutexes i asked about how they are used.Here i m attaching one code i hav tried in implementing queuing_mutex in the case of enqueuing and dequeuing of queue..i am facing errors when the input N value is 100 or more ..If possible can u tell me where i am getting the errors..

[Bartlomiej]

Dude, there are so many errors - not only conjuncted with parallelization...
First of all - you have two queues, but both of them share the same variables front and rear. How on Earth is this supposed to work?! If it was supposed to be so, this is a really bad programming style...

About parallelization - it is a deadly mistake that in enqueue() front is checked before the mutex is locked. A great place for race conditions.

But the main thing is that there is virtually no reason to use a queueing mutex here! An ordinary mutex would quite suffice and a spin mutex would be the best (as enqueue/dequeue operations do not require any iteration and should be rather quick).

I hope this helps. Try to clean the program and see how it works then.

(Edit) PS. Also, do not use rand() in multithreaded programs. It's not MT-safe as it uses a static(?) variable under the covers. Use rand_r() instead.

[praveen_satishgmail_]

Quoting - Bartlomiej

Dude, there are so many errors - not only conjuncted with parallelization...
First of all - you have two queues, but both of them share the same variables front and rear. How on Earth is this supposed to work?! If it was supposed to be so, this is a really bad programming style...

About parallelization - it is a deadly mistake that in enqueue() front is checked before the mutex is locked. A great place for race conditions.

But the main thing is that there is virtually no reason to use a queueing mutex here! An ordinary mutex would quite suffice and a spin mutex would be the best (as enqueue/dequeue operations do not require any iteration and should be rather quick).

I hope this helps. Try to clean the program and see how it works then.

(Edit) PS. Also, do not use rand() in multithreaded programs. It's not MT-safe as it uses a static(?) variable under the covers. Use rand_r() instead.

i am new to TBB and coding also .. can u correct it and attach here if possible.

[Bartlomiej]

Quoting - praveen.satishgmail.com

i am new to TBB and coding also .. can u correct it and attach here if possible.

If you're new to coding you shouldn't start with multithreaded programming. Study serial algorthms and data structures first.
And here is your more-ore-less-cleaned code.

[praveen_satishgmail_]

Quoting - Bartlomiej

If you're new to coding you shouldn't start with multithreaded programming. Study serial algorthms and data structures first.
And here is your more-ore-less-cleaned code.

yaa thank youu for your reply .. and for the code also .. this time we are having one course in parallel programming and i am having assignments in this area..