public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "gniccolai at yahoo dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/20099] -pthreads should imply -fno-threadsafe-statics Date: Thu, 24 Feb 2005 15:28:00 -0000 [thread overview] Message-ID: <20050224110006.12757.qmail@sourceware.org> (raw) In-Reply-To: <20050220004607.20099.davids@webmaster.com> [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2072 bytes --] ------- Additional Comments From gniccolai at yahoo dot com 2005-02-24 11:00 ------- (In reply to comment #18) > I think this is a waste really for this bug to be open as non of the GCC people commented on it and > when the orginal bug was filed, there was a huge opportunity to talk over this and nothing was done. > > So I am going to close as will not fix. Is there any of the GCC people in the POSIX committee working at the PTHREAD sub-standard? Because David Butenhof (member of the above and writer of the book "Programming with POSIX® Threads") has strongly argued against this feature: <cite> Obviously, (excessive) locking does NOT allow for simultaneous execution. A lot of people are used to write old good ST code and "add some locks to make it thread-safe" afterwards. The realworld result is always frustrating: the application is terribly slow and doesn't scale. Sure, we need some synchronization primitives (such as mutexes) to implement inter-thread communication. As a rule, thoroughly designed MT application is a set of fully independent threads which communicate via the message queues. The synchronization primitives are used inside these queues and virtually no locks are supposed outside the queues. But what we see in real life is herds of mutexes spread across the code. "MT-aware classes" try to lock almost every method... And even more, some "industrial-strength" PLs have the built-in mutex per every object! IMHO there is no excuse for this madness. </cite> I have found no other competent opinion arguing the other way around (that is, the thing that you want to do); every competent opinion is in this direction. The ABI closure is actually based on a non-standard solution, and on a "lack of interest" (and presumabily competence) in this field. Also, a bug cannot be considered closed "because no-one protested yet". BTW; I am going to see Stallman today and speak with him about this fact. Is in Milan today. Bests, Giancarlo Niccolai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20099
next prev parent reply other threads:[~2005-02-24 11:00 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 ` pinskia at gcc dot gnu dot org 2005-02-20 14:18 ` davids at webmaster dot com 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 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 [this message] 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=20050224110006.12757.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).