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


  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: link
Be 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).