Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
In-Reply-To: <20050404142507.GT1471@cygbert.vinschen.de>
References: <424D0232 DOT 5060305 AT smousseland DOT com> <20050401090414 DOT GD7415 AT cygbert DOT vinschen DOT de> <424D2B0B DOT 8000604 AT smousseland DOT com> <20050401121143 DOT GD1471 AT cygbert DOT vinschen DOT de> <424D5C64 DOT 5050706 AT smousseland DOT com> <20050401160749 DOT GH1471 AT cygbert DOT vinschen DOT de> <4250E410 DOT 1060708 AT smousseland DOT com> <20050404103824 DOT GS1471 AT cygbert DOT vinschen DOT de> <9305417ca9a2f2601ad20b83801d2f92 AT smousseland DOT com> <20050404142507 DOT GT1471 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5c59a962471bd65c3c3f3f44c37b8bf3@smousseland.com>
Content-Transfer-Encoding: 7bit
Reply-To: cygwin AT cygwin DOT com
From: Vincent Dedun <kraken AT smousseland DOT com>
Subject: Re: ipc, sockets and windows sp2
Date: Mon, 4 Apr 2005 18:05:12 +0200
To: cygwin AT cygwin DOT com

>> I just saw a strange stuff : in sysv_sem.cc (cygserver) at end of 
>> semop
>> function (:done2 label), the mutex is released after waking up waiting
>> process, shouldn't it be the inverse ?
>
> No, the mtx_unlock is correct.  If you're looking for bugs, they are 
> very
> likely in the bsd_* files in cygserver.  Even though the sysv_* files 
> taken
> from FreeBSD are not proved to be 100% correct, there's a high 
> probability
> that I produced the bug in some of the bsd emulation functions.  
> msleep is
> a good candidate, FWIW.
>
> Any active debugging or tracking down the bug is highly appreciated,
> probably not only by me.
>

there is a problem in bsd_mutex.cc I think.
the problems occurs as soon as msleep/wakeup stuffs are called, which 
means
msleep is never awaken by wakeup.

with previous testcase,
grepping cygserver debug output, show that, with 2 child process 
sharing mutex, wakeup is called first, then 2 msleep are called. So 
when msleep is called, wakeup has already been called, and msleep has 
to sleep forever.

this is a problem, as wakeup is called when another process is WAITING 
for the semaphore, and msleep is called when another process is LOCKING 
the semaphore.

a use of wakeup means another process called msleep before, so why 
seeing the first msleep after the only wakeup in the log ?

i don't have freebsd so i can't test this testcase on it, and i'm not 
sure if it relevant to sysv_sem.cc from bsd, or from bsd_mutex.cc not 
handling this as sysv_sem.cc expect it.

furthermore, when using 2 children and sleep(1) instead of usleep, show 
a strange behaviour, after a certain time (some seconds here), the 
semaphore get values like 6,9,10.. instead of 0,1.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/