This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Win32 error in C program using openmp and fork()
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 23 Jul 2013 16:39:10 +0200
- Subject: Re: Win32 error in C program using openmp and fork()
- References: <57302C57257EF2428CCAAF9BA83EC0448222C0EA at mbx08 dot adf dot bham dot ac dot uk> <20130722080657 dot GD2661 at calimero dot vinschen dot de> <51EE7700 dot 50803 at star dot sr dot bham dot ac dot uk> <20130723130851 dot GG9689 at calimero dot vinschen dot de> <20130723141855 dot GH9689 at calimero dot vinschen dot de>
- Reply-to: cygwin at cygwin dot com
On Jul 23 16:18, Corinna Vinschen wrote:
> On Jul 23 15:08, Corinna Vinschen wrote:
> > On Jul 23 13:28, Daniel Brown wrote:
> > > and that still had the fork error. I have also tried running in safe
> > > mode and
> > > stopping all my anti-virus software just incase that was interfering
> > > somehow.
> > > So I get as an output now...
> > >
> > > Daniel@XPS15z ~
> > > $ uname -r
> > > 1.7.22s(0.268/5/3)
> > >
> > > Daniel@XPS15z ~
> > > $ ./a.exe
> > > I'm an openmp thread...
> > > I'm an openmp thread...
> > > I'm an openmp thread...
> > > I'm an openmp thread...
> > > Parent fork 1 [main] a 5832 C:\cygwin\home\Daniel\a.exe: *** fatal
> > > error in forked process - failed
> > > to create new win32 semaphore, currentvalue -2, Win32 error 87
> > >
> > > However if I reduce the number of threads from 4 to 2 with:
> > >
> > > #pragma omp parallel num_threads(2)
> > > {
> > > printf("I'm an openmp thread...\n");
> > > }
> >
> > Ah, now there's something different. If I set the number of threads to
> > 4, I can reproduce this problem almost every try with currentvalue -2,
> > occassionally with currentvalue -1.
> >
> > > Looking at the source in thread.cc _fixup_after_fork() the win32
> > > error 87 is ERROR_INVALID_PARAMETER
> > > which is due to currentvalue < 0.
> > >
> > > My only guess is that there is a race condition on the
> > > currentvalue-- operations perhaps?
> >
> > Apparently. I investigate...
>
> Yes, there was a race condition in setting the value of the semaphore
> private "currentvalue" member. The only reason to keep track of the
> value is to allow _fixup_after_fork to set the right value, but here the
> race comes into play. I redesigned this part so that it only sets
> currentvalue once, right from fork itself, to propagate the correct
> value to the child process.
>
> I'm just building new 32 and 64 bit snapshots. They should be available
> on http://cygwin.com/snapshots/ in an hour at the latest. Please give
> it a try.
Both snapshots are up. Test away.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple