This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: fix cond_race... was RE: src/winsup/cygwin ChangeLog thread.cc thread.h ...
- To: Robert Collins <robert dot collins at itdomain dot com dot au>
- Subject: Re: fix cond_race... was RE: src/winsup/cygwin ChangeLog thread.cc thread.h ...
- From: Jason Tishler <jason at tishler dot net>
- Date: Sun, 21 Oct 2001 21:35:45 -0400
- Cc: cygwin-patches at cygwin dot com
Rob,
On Sun, Oct 07, 2001 at 10:24:30PM +1000, Robert Collins wrote:
> From: "Jason Tishler" <jason@tishler.net>
> > Unfortunately, Python's test_threadedtempfile regression test still
> > hangs (IIRC) in the same place. See attached for details.
>
> I'm going to have to think about this one - unless your systems is
> massively overloaded during the test - such that the spinloop around
> line 482 is able to get 10 timeslices without the waiting thread getting
> 1?!? - there should be no way to tickle this.
>
> I'd like you to add a system_printf, at line 483, something like
> "system_printf ("repulsing event at count 5\n"); (oh, and put it at the
> PulseEvent in {}. If that fires then we know that the detection code is
> ok. If so, can you try bumping the spin count up, and make the pulsevent
> fire if spins mod 5 == 0 ?
With the attached patch applied to thread.cc version 1.52, Python's
test_threadedtempfile regression test still hangs in the same place.
Did I alter the code as you intended above or did I misunderstand?
When I run test_threadedtempfile, I get the following output:
0 [main] python 2024 pthread_cond::Signal: repulsing event at count 995
9323 [main] python 2024 pthread_cond::Signal: repulsing event at count 990
20154 [main] python 2024 pthread_cond::Signal: repulsing event at count 985
..
316104517 [main] python 2024 pthread_cond::Signal: repulsing event at count 10
316116338 [main] python 2024 pthread_cond::Signal: repulsing event at count 5
316124566 [main] python 2024 pthread_cond::Signal: repulsing event at count 0
316136630 [unknown (0x520)] python 2024 pthread_cond::Signal: repulsing event at
count 995
316144651 [unknown (0x520)] python 2024 pthread_cond::Signal: repulsing event at
count 990
316156310 [unknown (0x520)] python 2024 pthread_cond::Signal: repulsing event at
count 985
..
382360754 [unknown (0x520)] python 2024 pthread_cond::Signal: repulsing event at
count 10
382369786 [unknown (0x520)] python 2024 pthread_cond::Signal: repulsing event at
count 5
382380484 [unknown (0x520)] python 2024 pthread_cond::Signal: repulsing event at
count 0
..
So the repulse event is occurring, but I don't think that it is having any
affect.
Is there anything else that you would like me to try?
Thanks,
Jason
Index: thread.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/thread.cc,v
retrieving revision 1.52
diff -u -p -r1.52 thread.cc
--- thread.cc 2001/09/30 14:39:55 1.52
+++ thread.cc 2001/10/22 01:28:08
@@ -504,17 +504,20 @@ pthread_cond::Signal ()
/* The released thread will decrement waiting when it gets a time slice...
without waiting for the access mutex
*/
- int spins = 10;
+ int spins = 1000;
while (InterlockedIncrement (&waiting) != (temp - 1) && spins)
{
InterlockedDecrement (&waiting);
/* give up the cpu to force a context switch. */
Sleep (0);
- if (spins == 5)
+ spins--;
+ if (spins % 5 == 0)
+ {
/* we've had 5 timeslices, and the woekn thread still hasn't done it's
* thing - maybe we raced it with the event? */
PulseEvent (win32_obj_id);
- spins--;
+ system_printf ("repulsing event at count %d\n", spins);
+ }
}
InterlockedDecrement (&waiting);
if (pthread_mutex_unlock (&cond_access))