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:18:55 +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>
- Reply-to: cygwin at cygwin dot com
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.
Thanks,
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