Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
In-Reply-To: <20050406111752.GG1471@cygbert.vinschen.de>
References: <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> <5c59a962471bd65c3c3f3f44c37b8bf3 AT smousseland DOT com> <20050406111752 DOT GG1471 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: <c354d01fa19910e21fe067e9ec1745ce@smousseland.com>
Content-Transfer-Encoding: 7bit
Reply-To: cygwin AT cygwin DOT com
From: kraken+spam AT smousseland DOT com
Subject: Re: ipc, sockets and windows sp2
Date: Fri, 8 Apr 2005 17:10:08 +0200
To: cygwin AT cygwin DOT com


> On Apr  4 18:05, Vincent Dedun wrote:
>> 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.
>
> What you see is intermixed debug output of different threads.  The log
> output is not guranteed to be in the right order.  I've improved debug
> output slightly so that it's at least possible to recognize mtx_locks
> and mtx_unlocks which are connected and who's the current owner of a
> mtx_lock.
>
> I have debugged cygserver now for two days and have found various bugs,
> one showing up as soon as another one was fixed.  I've rewritten the
> whole thread synchronization and I've even found a synchronization bug
> in the BSD code (which probably is no problem when running in the BSD
> kernel).
>

oh great, thank you for working on this.

> I've checked in a pretty big patch which works fine for me (but what
> does that count?)
>

it works for me too for the testcase i provided last time.

But there is still some issues when you run several semaphore-using 
program at the same time.

to reproduce it :
-compil last testcase with this modification :

-- if (n_children < 20)
instead of
-- if (n_children < 1)
at the beginning of the main loop

and change
-- usleep(10)
to
-- sleep(1)
so childs does not disappear too quickly.

-compile it, and copy the binary in another place (like /tmp), so you 
can run two instance of it (as semaphore key is created from the path, 
must have different path).

-then run both of them, you should see
--semaphore_lock: Identifier removed
messages, and your semaphores aren't locked.

you can give -r 64 argument to cygserver to be sure that it is not a 
query thread number issue.

the message may disappear after a certain moment and your semaphore 
then works.
when you run again the testcase binary, cygserver may not respond 
anymore after that.
all this depending on how much query and cleaning thread you asked to 
cygwin

on the software i'm working one, semaphore not being locked perturb the 
execution, so i have to either disable the semaphores (as it is not 
locked with this error), or run slave and master on different computer 
(but most people would like to use the master as a slave too).

I tried to lower the listening children as much as possible, but the 
problem will always occure after some minutes of usage (I think when 
there is too much active children).

Thank you for your wonderful work.

Kraken


--
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/