This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/33892] [libstdc++ v3 parallel mode] Parallel mode algorithms use critical sections with global scope
- From: "jakub at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 30 Oct 2007 07:12:36 -0000
- Subject: [Bug libstdc++/33892] [libstdc++ v3 parallel mode] Parallel mode algorithms use critical sections with global scope
- References: <bug-33892-15121@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #2 from jakub at gcc dot gnu dot org 2007-10-30 07:12 -------
Looks good to me. Something like __gnu_cxx::scoped_lock is unnecessary, the
current use of #pragma omp critical to be replaced by omp_*_lock with this
patch
is always inside of some #pragma omp parallel and there is no try { ... } catch
(xxx) construct around it. So if some routine throws an exception while the
lock is held, the app will be std::terminate anyway, at which point it doesn't
matter whether the lock is held or not.
The only header where such a region could potentially throw is workstealing.h,
everything else doesn't call functions, or calls just std::min and as I said
above, if it would throw, it would kill the program anyway.
BTW, compatibility.h is horribly i?86/x86_64 centric, there are many other
arches
which support 64-bit __sync_fetch_and_add and __sync_bool_compare_and_swap
(e.g. ia64, ppc64, sparc64, sparcv9, s390x, I believe also s390, etc.).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33892