https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Cannot-hold-locks-at-a-thread-boundary/m-p/854678#M2030 Hi wml, <BR />Thanks for an illustrative example ... <BR />pkroy <DIV style="margin:0px;"> <DIV id="quote_reply" style="margin-top: 5px; width: 100%;"> <DIV style="margin-left:2px;margin-right:2px;">Quoting - <A href="https://community.intel.com/en-us/profile/450889">William Leiserson (Intel)</A></DIV> <DIV style="background-color:#E5E5E5; padding:5px;border: 1px; border-style: inset;margin-left:2px;margin-right:2px;"><EM>Hi Pkroy,<BR /><BR />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:<BR /><BR />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.<BR /><BR />2. You can deadlock, inadvertantly. Consider the following example:<BR /><BR />void f (lock) {<BR />acquire(lock);<BR />do_work();<BR />release(lock);<BR />}<BR /><BR />void g (lock) {<BR />spawn f();<BR />acquire(lock);<BR />do_work();<BR />sync;<BR />release(lock);<BR />}<BR /><BR />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.<BR /><BR />---<BR /><BR />For these reasons, cilkscreen will generate an error if you are holding a lock across a spawn or sync boundary.<BR /><BR />-wml<BR /></EM></DIV> </DIV> </DIV> <BR /> Sat, 09 Jan 2010 09:20:30 GMT pkroy 2010-01-09T09:20:30Z https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Cannot-hold-locks-at-a-thread-boundary/m-p/854676#M2028 <DIV>Hi all,</DIV> <DIV><BR /></DIV> <DIV><BR /></DIV> I am using cilk++ in my application. While using cilkscreen i get the following message : <DIV>Cannot hold locks at a thread boundary</DIV> <DIV><BR /></DIV> <DIV>What does it mean ???</DIV> <DIV><BR /></DIV> <DIV>I am doing something like this :</DIV> <DIV><BR /></DIV> <DIV>void my_Recursive_fn()</DIV> <DIV>{</DIV> <DIV><BR /></DIV> <DIV>if ( base_case){</DIV> <DIV>work0</DIV> <DIV>return;</DIV> <DIV>}</DIV> <DIV>else</DIV> <DIV>{</DIV> <DIV>work1</DIV> <DIV>spawn my_Recursive_fn();</DIV> <DIV>my_Recursive_fn();</DIV> <DIV>sync;</DIV> <DIV>}</DIV> <DIV>return;</DIV> <DIV>}</DIV> <DIV><BR /></DIV> <DIV><BR /></DIV> <DIV><BR /></DIV> Wed, 23 Dec 2009 19:33:02 GMT https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Cannot-hold-locks-at-a-thread-boundary/m-p/854676#M2028 pkroy 2009-12-23T19:33:02Z https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Cannot-hold-locks-at-a-thread-boundary/m-p/854677#M2029 <DIV style="margin:0px;"> <DIV id="quote_reply" style="margin-top: 5px; width: 100%;"> <DIV style="margin-left:2px;margin-right:2px;">Quoting - <A href="https://community.intel.com/en-us/profile/452527">pkroy</A></DIV> <DIV style="background-color:#E5E5E5; padding:5px;border: 1px; border-style: inset;margin-left:2px;margin-right:2px;"><EM> <DIV>Hi all,</DIV> <DIV><BR /></DIV> <DIV><BR /></DIV> I am using cilk++ in my application. While using cilkscreen i get the following message : <DIV>Cannot hold locks at a thread boundary</DIV> <DIV><BR /></DIV> <DIV>What does it mean ???</DIV> <DIV><BR /></DIV> <DIV>I am doing something like this :</DIV> <DIV><BR /></DIV> <DIV>void my_Recursive_fn()</DIV> <DIV>{</DIV> <DIV><BR /></DIV> <DIV>if ( base_case){</DIV> <DIV>work0</DIV> <DIV>return;</DIV> <DIV>}</DIV> <DIV>else</DIV> <DIV>{</DIV> <DIV>work1</DIV> <DIV>spawn my_Recursive_fn();</DIV> <DIV>my_Recursive_fn();</DIV> <DIV>sync;</DIV> <DIV>}</DIV> <DIV>return;</DIV> <DIV>}</DIV> <DIV><BR /></DIV> <DIV><BR /></DIV> <DIV><BR /></DIV> </EM></DIV> </DIV> </DIV> <BR />Hi Pkroy,<BR /><BR />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:<BR /><BR />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.<BR /><BR />2. You can deadlock, inadvertantly. Consider the following example:<BR /><BR />void f (lock) {<BR /> acquire(lock);<BR /> do_work();<BR /> release(lock);<BR />}<BR /><BR />void g (lock) {<BR />spawn f();<BR /> acquire(lock);<BR /> do_work();<BR /> sync;<BR /> release(lock);<BR />}<BR /><BR />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.<BR /><BR />---<BR /><BR />For these reasons, cilkscreen will generate an error if you are holding a lock across a spawn or sync boundary.<BR /><BR />-wml<BR /> Mon, 04 Jan 2010 20:57:03 GMT https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Cannot-hold-locks-at-a-thread-boundary/m-p/854677#M2029 William_Leiserson__I 2010-01-04T20:57:03Z https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Cannot-hold-locks-at-a-thread-boundary/m-p/854678#M2030 Hi wml, <BR />Thanks for an illustrative example ... <BR />pkroy <DIV style="margin:0px;"> <DIV id="quote_reply" style="margin-top: 5px; width: 100%;"> <DIV style="margin-left:2px;margin-right:2px;">Quoting - <A href="https://community.intel.com/en-us/profile/450889">William Leiserson (Intel)</A></DIV> <DIV style="background-color:#E5E5E5; padding:5px;border: 1px; border-style: inset;margin-left:2px;margin-right:2px;"><EM>Hi Pkroy,<BR /><BR />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:<BR /><BR />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.<BR /><BR />2. You can deadlock, inadvertantly. Consider the following example:<BR /><BR />void f (lock) {<BR />acquire(lock);<BR />do_work();<BR />release(lock);<BR />}<BR /><BR />void g (lock) {<BR />spawn f();<BR />acquire(lock);<BR />do_work();<BR />sync;<BR />release(lock);<BR />}<BR /><BR />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.<BR /><BR />---<BR /><BR />For these reasons, cilkscreen will generate an error if you are holding a lock across a spawn or sync boundary.<BR /><BR />-wml<BR /></EM></DIV> </DIV> </DIV> <BR /> Sat, 09 Jan 2010 09:20:30 GMT https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Cannot-hold-locks-at-a-thread-boundary/m-p/854678#M2030 pkroy 2010-01-09T09:20:30Z https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Cannot-hold-locks-at-a-thread-boundary/m-p/854679#M2031 <DIV style="margin:0px;">No problem. :)<BR /></DIV> Mon, 11 Jan 2010 14:54:16 GMT https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Cannot-hold-locks-at-a-thread-boundary/m-p/854679#M2031 William_Leiserson__I 2010-01-11T14:54:16Z