Cannot hold locks at a thread boundary

Cannot hold locks at a thread boundary

Hi all,

I am using cilk++ in my application. While using cilkscreen i get the following message :
Cannot hold locks at a thread boundary

What does it mean ???

I am doing something like this :

void my_Recursive_fn()
{

if ( base_case){
work0
return;
}
else
{
work1
spawn my_Recursive_fn();
my_Recursive_fn();
sync;
}
return;
}

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Quoting - pkroy

Hi all,

I am using cilk++ in my application. While using cilkscreen i get the following message :
Cannot hold locks at a thread boundary

What does it mean ???

I am doing something like this :

void my_Recursive_fn()
{

if ( base_case){
work0
return;
}
else
{
work1
spawn my_Recursive_fn();
my_Recursive_fn();
sync;
}
return;
}

Hi Pkroy,

This error is an indication that you are holding a lock across a spawn or sync. Cilkscreen complains about this for a couple of reasons:

1. The thread that is running just after a spawn or sync statement is not necessarily the same one that was running beforehand. This means that the acquire() and release() functions may be called on different threads, which is not permitted on certain kinds of locks on Windows or on pthread mutexes.

2. You can deadlock, inadvertantly. Consider the following example:

void f (lock) {
acquire(lock);
do_work();
release(lock);
}

void g (lock) {
spawn f();
acquire(lock);
do_work();
sync;
release(lock);
}

In this case, if the acquire() in g() is executed before the acquire() in f(), then the program will deadlock because the release() in g() cannot be executed until after f() has returned and g() has been able to sync. But f() will never return.

---

For these reasons, cilkscreen will generate an error if you are holding a lock across a spawn or sync boundary.

-wml

Hi wml,
Thanks for an illustrative example ...
pkroy

Quoting - William Leiserson (Intel)
Hi Pkroy,

This error is an indication that you are holding a lock across a spawn or sync. Cilkscreen complains about this for a couple of reasons:

1. The thread that is running just after a spawn or sync statement is not necessarily the same one that was running beforehand. This means that the acquire() and release() functions may be called on different threads, which is not permitted on certain kinds of locks on Windows or on pthread mutexes.

2. You can deadlock, inadvertantly. Consider the following example:

void f (lock) {
acquire(lock);
do_work();
release(lock);
}

void g (lock) {
spawn f();
acquire(lock);
do_work();
sync;
release(lock);
}

In this case, if the acquire() in g() is executed before the acquire() in f(), then the program will deadlock because the release() in g() cannot be executed until after f() has returned and g() has been able to sync. But f() will never return.

---

For these reasons, cilkscreen will generate an error if you are holding a lock across a spawn or sync boundary.

-wml

No problem. :)

Leave a Comment

Please sign in to add a comment. Not a member? Join today