From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2446 invoked by alias); 10 Nov 2009 04:06:45 -0000 Received: (qmail 2437 invoked by uid 22791); 10 Nov 2009 04:06:44 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from virtual.bogons.net (HELO virtual.bogons.net) (193.178.223.136) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Nov 2009 04:06:39 +0000 Received: from jifvik.dyndns.org (jifvik.dyndns.org [85.158.45.40]) by virtual.bogons.net (8.10.2+Sun/8.11.2) with ESMTP id nAA46a428557; Tue, 10 Nov 2009 04:06:36 GMT Received: from [172.31.1.126] (neelix.jifvik.org [172.31.1.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jifvik.dyndns.org (Postfix) with ESMTP id E55EF3FF4; Tue, 10 Nov 2009 04:06:35 +0000 (GMT) Message-ID: <4AF8E6CB.1090008@jifvik.org> Date: Tue, 10 Nov 2009 04:06:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) MIME-Version: 1.0 To: Jerome Souquieres Cc: ecos-devel@ecos.sourceware.org Subject: Re: pthread_once non conformant References: <1ca1a2b60911011252v76b5626cwd8b6fca144c857f2@mail.gmail.com> In-Reply-To: <1ca1a2b60911011252v76b5626cwd8b6fca144c857f2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-11/txt/msg00001.txt.bz2 Jerome Souquieres wrote: > Hi, > > I think I've spotted a bug in pthread_once (in ecos v3.0). The current > implementation does not enforce the part of the specification that > says: "On return from pthread_once(), it is guaranteed that > init_routine() has completed". > > Here is a proposal for a patch, I did not post it to ecos-patches > because I currently don't have a working eCos target to test this. [Patch at end] Thanks. I agree there's a problem here, but the fix isn't right - you can't leave pthread_mutex locked while running an arbitrary user routine. You'll get a potential deadlock, or at least incorrect operation of the pthread layer if anything uses pthread functions before the user function terminates (which could be never). The real solution probably involves linking a condition variable to pthread_mutex and having an additional state for once_control to indicate "once function being run but not yet complete". Any thread which sees the once_control in that state will have to wait on the condvar (which is then broadcast on when the once function returns). Would you be able to make a fix along those lines? Or failing that if you submit it to http://bugs.ecos.sourceware.org/ it won't get lost at least. Jifl > --- pthread.cxx 2009-01-29 18:47:52.000000000 +0100 > +++ pthread-fixonce.cxx 2009-11-01 21:07:42.639875000 +0100 > @@ -1328,22 +1328,23 @@ externC int pthread_once (pthread_once_t > PTHREAD_ENTRY(); > > PTHREAD_CHECK( once_control ); > PTHREAD_CHECK( init_routine ); > > - pthread_once_t old; > - > - // Do a test and set on the once_control object. > pthread_mutex.lock(); > > - old = *once_control; > - *once_control = 1; > + // If the once_control is zero, call the init_routine(). > + // the mutex must stay locked during init_routine because > + // concurrent threads must be blocked until init_routine has > + // done its business > + if ( !*once_control ) > + { > + init_routine(); > + *once_control = 1; > + } > > pthread_mutex.unlock(); > - > - // If the once_control was zero, call the init_routine(). > - if( !old ) init_routine(); > > PTHREAD_RETURN(0); > } > -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine