This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/20099] -pthreads should imply -fno-threadsafe-statics


------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]