This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting


http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> 2011-09-26 16:19:50 UTC ---
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.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]