public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "davids at webmaster dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/20099] -pthreads should imply -fno-threadsafe-statics Date: Mon, 21 Feb 2005 09:29:00 -0000 [thread overview] Message-ID: <20050220194347.13227.qmail@sourceware.org> (raw) In-Reply-To: <20050220004607.20099.davids@webmaster.com> ------- Additional Comments From davids at webmaster dot com 2005-02-20 19:43 ------- >The reasoning is that dynamically created objects are often used locally in one >thread, in which case locking would be unnecessary, while a singleton is always >accessible to all threads. Accessible, but not necessarily accessed. In fact, there is no way you can know whether this synchronization overhead is necessary, and for POSIX it's only needed if the code violates the memory visibility rules. >Static locals in C++ are an equivalent to pthread_once in C/POSIX. Even in the single-threaded case, C++ leaves it undefined what happens if you reenter a function that invokes a static initializer from that static initializer. To argue that this means it should be defined for the multi-threaded case is absurd. C++ requires the initialization to be complete before you are allowed to pass the intializer again. POSIX requires locks when data that might be shared might be modified. Bluntly, this is totally opposite to the entire philosophy of the POSIX standard and the wording of the C++ standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20099
next prev parent reply other threads:[~2005-02-20 19:44 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-02-20 13:52 [Bug c++/20099] New: " davids at webmaster dot com 2005-02-20 14:17 ` [Bug c++/20099] " pinskia at gcc dot gnu dot org 2005-02-20 14:18 ` davids at webmaster dot com 2005-02-20 14:18 ` pinskia at gcc dot gnu dot org 2005-02-20 14:22 ` pinskia at gcc dot gnu dot org 2005-02-20 15:07 ` davids at webmaster dot com 2005-02-20 15:11 ` davids at webmaster dot com 2005-02-20 15:37 ` pinskia at gcc dot gnu dot org 2005-02-20 17:07 ` qrczak at knm dot org dot pl 2005-02-20 17:15 ` davids at webmaster dot com 2005-02-20 18:12 ` qrczak at knm dot org dot pl 2005-02-21 9:29 ` davids at webmaster dot com [this message] 2005-02-21 12:04 ` qrczak at knm dot org dot pl 2005-02-21 15:45 ` gniccolai at yahoo dot com 2005-02-21 16:34 ` davids at webmaster dot com 2005-02-22 15:59 ` gniccolai at yahoo dot com 2005-02-23 11:55 ` davids at webmaster dot com 2005-02-23 11:57 ` qrczak at knm dot org dot pl 2005-02-23 12:26 ` pinskia at gcc dot gnu dot org 2005-02-23 12:28 ` davids at webmaster dot com 2005-02-24 15:28 ` gniccolai at yahoo dot com 2005-02-24 20:00 ` gniccolai at yahoo dot com 2005-02-24 22:02 ` qrczak at knm dot org dot pl 2005-02-25 1:37 ` davids at webmaster dot com 2005-02-25 1:41 ` qrczak at knm dot org dot pl 2005-02-25 3:30 ` davids at webmaster dot com 2005-02-25 4:37 ` qrczak at knm dot org dot pl 2005-02-25 8:06 ` davids at webmaster dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20050220194347.13227.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).