From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7397 invoked by alias); 24 Feb 2005 23:45:48 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 7363 invoked by uid 48); 24 Feb 2005 23:45:43 -0000 Date: Fri, 25 Feb 2005 08:06:00 -0000 Message-ID: <20050224234543.7362.qmail@sourceware.org> From: "davids at webmaster dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050220004607.20099.davids@webmaster.com> References: <20050220004607.20099.davids@webmaster.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/20099] -pthreads should imply -fno-threadsafe-statics X-Bugzilla-Reason: CC X-SW-Source: 2005-02/txt/msg03074.txt.bz2 List-Id: ------- Additional Comments From davids at webmaster dot com 2005-02-24 23:45 ------- > The difference is that almost all uses of strchr are done on data > which is not shared between threads, while many static local > initializers are used on objects which are accessed from multiple > threads (when multiple threads are used at all). In both cases, some are, some aren't. Some uses of 'strchr' are on data that's used by multiple threads. And some object intialized statically are in functions that are only called by a single thread. The cases are not as different as you seem to think they are. > By your reasoning malloc should be unsafe to use from multiple threads > if the user did not explicitly put a lock around it, because it modifies > shared data (the heap). The difference is that 'malloc' is a function supplied by the system and the user, in principle, has no knowledge of its internals. In principle, the user has no idea that there is a "heap" or that it is a shared structure. To support your argument, you would have to argue that if the user tried to implement his own memory allocation function, the language should somehow detect that it manipulates a shared structure (like the heap) and apply locks around that structure. > And errno should not be automatically made > thread-local, because it hurts performance in case thread-locality is not > needed. Again, to make your argument work, you would have to argue that the system should detect that new user-written code accesses some static variable akin to 'errno' and automatically change that variable to be thread local. > After all, "POSIX puts the responsibility fully on the application > programmer to place locks where there might be concurrent access. In > exchange for this effort, the programmer gets the performance benefit > of there not being locks when they are not needed". > Right? Right. User code should not get automatic locks put around it. Locks are needed where the programmer couldn't possibly know that shared data is manipulated, and the locks should be coded in the function, not magically added by the language. None of your cases even remotely support the argument that the implementation should detect possible cases where data is modified in one thread while it's used in another thread and automatically insert locks to make this access safe. (In the context of POSIX threads.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20099