After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 512624 - Race condition in threadpool-test
Race condition in threadpool-test
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
2.15.x
Other All
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2008-01-28 18:09 UTC by Simon Murray
Modified: 2008-01-29 10:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Simon Murray 2008-01-28 18:09:43 UTC
Please describe the problem:
"test_thread_pools" does an unatomic add of "leftover_task_counter", while "test_thread_pools_entry_func" does an atomic decrement.  The race occurs when the main thread reads the value from memory, a worker thread decrements leftover_task_counter, then the main thread commits back to memory thus losing the atomic decrement done by the worker.

Steps to reproduce:
1. Bump "runs" in "test_thread_pools" up to something large (I used 30000) so that worker threads are running while the main thread is still pushing jobs into the thread pools


Actual results:
** ERROR:(threadpool-test.c:196):test_thread_pools: assertion failed: (runs * 3 == abs_thread_counter + leftover_task_counter)

Expected results:
Non-deterministic fails, about 3 in 20 runs; tested on POWER6 

Does this happen every time?
no

Other information:
Can be fixed by grabbing the "thread_counter_pools" lock when we do "leftover_task_counter += 3;".  Seems to happen more reliably on 2.12 for both POWER and i686, not sure why.
Comment 1 Sebastian Wilhelmi 2008-01-29 10:08:03 UTC
2008-01-29  Sebastian Wilhelmi  <wilhelmi@google.com>

	* tests/threadpool-test.c (test_thread_pools): Grab
	thread_counter_pools LOCK when increasing
	leftover_task_counter. Fixes race in test. (#512624, Simon Murray)