This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting
- From: "mihaylov.mihail at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Tue, 27 Sep 2011 10:13:25 +0000
- Subject: [Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting
- Auto-submitted: auto-generated
- References: <bug-13165-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=13165
--- Comment #10 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2011-09-27 10:13:25 UTC ---
(In reply to comment #8)
> Could you simplify it? I'm not sure why the test has to be so much more
> complicated than your real code. If you think there's a race/bug in cond vars,
> then it's probably not a good idea to be using cond vars in the logic for the
> test loop, since it will be hard to tell if the bug is occurring in the tested
> code or the control code. Perhaps you could use barriers or semaphores to
> synchronize the test control logic, if needed. Personally barriers are my
> favorite synchronization primitive for that sort of thing.
>
> Also, yes, get rid of the "make as many threads as possible" logic. That will
> not make it any easier to find the race, and the limit to how many threads you
> can make is usually dependent on available memory/virtual address space, not
> kernel thread resources. Just pick a "sane" number (probably below 100) and go
> with it.
I simplified the test significantly as you suggested. Now its somewhat simpler
than my actual code.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.