Mail Archives: cygwin/2005/04/04/12:06:33
>> 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/
- Raw text -