public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jifl@jifvik.org>
To: Jerome Souquieres <jerome.souquieres@gmail.com>
Cc: ecos-devel@ecos.sourceware.org
Subject: Re: pthread_once non conformant
Date: Tue, 10 Nov 2009 04:06:00 -0000	[thread overview]
Message-ID: <4AF8E6CB.1090008@jifvik.org> (raw)
In-Reply-To: <1ca1a2b60911011252v76b5626cwd8b6fca144c857f2@mail.gmail.com>

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

  reply	other threads:[~2009-11-10  4:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-01 20:52 Jerome Souquieres
2009-11-10  4:06 ` Jonathan Larmour [this message]
2009-11-10 15:24   ` Jerome Souquieres

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=4AF8E6CB.1090008@jifvik.org \
    --to=jifl@jifvik.org \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=jerome.souquieres@gmail.com \
    /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).