Comments on: Scoped locking vs. critical in OpenMP - a personal shootout http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/ A Blog on Parallel Programming and Concurrency by Michael Suess Wed, 09 Jul 2008 02:32:16 +0000 http://wordpress.org/?v=2.5 By: Chirag Singla http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/#comment-30923 Chirag Singla Mon, 12 Nov 2007 17:04:07 +0000 http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/#comment-30923 Really nice article:) Really nice article:)

]]> By: Brandon Barker http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/#comment-16573 Brandon Barker Mon, 09 Jul 2007 02:35:29 +0000 http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/#comment-16573 Thanks for the very helpful article! Thanks for the very helpful article!

]]> By: Michael Suess http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/#comment-4714 Michael Suess Fri, 23 Mar 2007 12:40:00 +0000 http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/#comment-4714 Always glad to help... Always glad to help…

]]> By: Jeremy Rogers http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/#comment-4696 Jeremy Rogers Fri, 23 Mar 2007 03:22:40 +0000 http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/#comment-4696 ^^^ Gee, gush much? :) ^^^ Gee, gush much? :)

]]> By: Jeremy Rogers http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/#comment-4695 Jeremy Rogers Fri, 23 Mar 2007 03:21:11 +0000 http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/#comment-4695 Thanks for the excellent article! As a student starting to learn about parallel programming, I was wondering exactly what this article addresses. Thanks for a well-put-together article. For once, my question got answered with exactly one search. Thank you again for the great article. Thanks for the excellent article! As a student starting to learn about parallel programming, I was wondering exactly what this article addresses. Thanks for a well-put-together article. For once, my question got answered with exactly one search. Thank you again for the great article.

]]> By: Michael Suess http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/#comment-21 Michael Suess Wed, 23 Aug 2006 21:11:22 +0000 http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/#comment-21 Joe, thanks for your comment. The article presented here is for an audience that are not beginners in parallel programming. I thought about whether or not to include a section discussing the more general issue of locking and when it is needed, but this would have blown it way out of proportion and would have bored the heck out of the more advanced readers who (hopefully) find the rest of the article more interesting. That said, I totally agree with you, locking should be avoided whenever possible, I am also telling this to my students quite frequently and do not even want to think about the amount of time I have spent optimizing out critical regions in my code ;-). That said, there is another thing I obviously did not make sufficiently clear: The critical region in the last example does not serve to protect the rand()-function, but was rather meant to protect the data-variable. I should have made that more clear I guess. In OpenMP it is not necessary to protect the call to rand (), as all library functions supplied by the base language are required to be thread-safe by the specification. Nevertheless, you are still right, using rand() was not the brightest thing to do, I should have rather used something less specific like some_function_foo() ;-). Joe,
thanks for your comment. The article presented here is for an audience that are not beginners in parallel programming. I thought about whether or not to include a section discussing the more general issue of locking and when it is needed, but this would have blown it way out of proportion and would have bored the heck out of the more advanced readers who (hopefully) find the rest of the article more interesting.

That said, I totally agree with you, locking should be avoided whenever possible, I am also telling this to my students quite frequently and do not even want to think about the amount of time I have spent optimizing out critical regions in my code ;-).

That said, there is another thing I obviously did not make sufficiently clear: The critical region in the last example does not serve to protect the rand()-function, but was rather meant to protect the data-variable. I should have made that more clear I guess. In OpenMP it is not necessary to protect the call to rand (), as all library functions supplied by the base language are required to be thread-safe by the specification. Nevertheless, you are still right, using rand() was not the brightest thing to do, I should have rather used something less specific like some_function_foo() ;-).

]]> By: Joe http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/#comment-19 Joe Wed, 23 Aug 2006 18:49:13 +0000 http://www.thinkingparallel.com/2006/08/21/scoped-locking-vs-critical-in-openmp-a-personal-shootout/#comment-19 Nice article. A point that I try to emphasize to students when I teach a course on HPC programming using OpenMP and MPI, is that critical sections of any sort are points of serialization in code, and should be avoided whenever possible. Some things cannot be done without locks and critical sections. You gave rand as an example. It turns out in the rand case that there are better solutions. Given the typical use case for rand, you can actually light off numerous independent PRNGs which don't depend upon global hidden state (which is what the lock attempts to serialize for you). Basically what I am advocating is, whenever possible, try to avoid locking, and try to avoid serialized/serializing regions or function calls. In any parallel program, serialized regions are responsible for the "s" part in Amdahl's law, and you want that as small as possible. Nice article. A point that I try to emphasize to students when I teach a course on HPC programming using OpenMP and MPI, is that critical sections of any sort are points of serialization in code, and should be avoided whenever possible. Some things cannot be done without locks and critical sections. You gave rand as an example. It turns out in the rand case that there are better solutions. Given the typical use case for rand, you can actually light off numerous independent PRNGs which don’t depend upon global hidden state (which is what the lock attempts to serialize for you).

Basically what I am advocating is, whenever possible, try to avoid locking, and try to avoid serialized/serializing regions or function calls. In any parallel program, serialized regions are responsible for the “s” part in Amdahl’s law, and you want that as small as possible.

]]>