From: tangchen <tan...@cn...> - 2011-06-30 01:33:31
|
hi, The case pthread_cond_init/1-2.c sometimes passed, but sometimes failed on my box. OS: RHEL6.1GA x86_64 Memory: 4GB CPU: Xeon E5506 2.13GHz, 4 cores When it failed, I got the following messages: # ./1-2.run-test Test starting... Timers option : 200809 Clock Selection option : 200809 Starting clock test Data initialized successfully for CS test. Sysconf for monotonix clock: 200809 clock_settime succeeded Monotonic clock : 200470.244301499 Default clock : 1310609518.800609262 Computed diff : 1310409048.556307763 With monotonic smaller than default Two threads are created and waiting. About to change the default clock value. Checking that both threads have timedout... The thread was not woken when the clock was changed so as the timeout expired Going to simulate this POSIX behavior... Rechecking that both threads have timedout... Null attribute cond var timed out Default attribute cond var did not time out Default clock was set back using monotonic clock as a reference Default attribute cond var timedwait return value: 0 Default attribute cond var exited with a timeout : no Default attribute cond var had to be signaled : yes Default attribute cond var exited as signaled : yes Default attribute cond var spurious wakeups : 0 Null attribute cond var timedwait return value: 110 Null attribute cond var exited with a timeout : yes Null attribute cond var had to be signaled : no Null attribute cond var exited as signaled : no Null attribute cond var spurious wakeups : 0 Test ../../../conformance/interfaces/pthread_cond_init/1-2.c FAILED: The cond vars use different clocks. I think perhaps it has something to do with the scheduler. The case calls sched_yield(), which calls __switch() directly in the kernel. But maybe a very short time later, the main thread is scheduled again, but not any of the child thread. As a result, sometimes the case passed, and sometimes failed. I replace it with sleep(1), and I think 1 second is long enough to ensure two children threads is scheduled. and now, the case always passes. Here is the patch, please comment.:) Signed-off-by: Tang Chen <tan...@cn...> --- .../conformance/interfaces/pthread_cond_init/1-2.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_cond_init/1-2.c b/testcases/open_posix_testsuite/conformance/interfaces/pthread_cond_init/1-2.c index 60ec77b..7f31ca2 100644 --- a/testcases/open_posix_testsuite/conformance/interfaces/pthread_cond_init/1-2.c +++ b/testcases/open_posix_testsuite/conformance/interfaces/pthread_cond_init/1-2.c @@ -371,7 +371,7 @@ int do_cs_test(void) if (ret != 0) { UNRESOLVED(ret, "Unable to unlock a mutex"); } /* Let the others threads run */ - sched_yield(); + sleep(1); #if VERBOSE > 1 output("Checking that both threads have timedout...\n"); @@ -636,4 +636,4 @@ int main(int argc, char * argv[]) { FAILED("The cond vars use different clocks."); } PASSED; -} \ No newline at end of file +} -- 1.7.1 -- Best Regards, Tang chen |
From: tangchen <tan...@cn...> - 2011-06-30 08:34:16
|
On 06/30/2011 09:32 AM, tangchen wrote: > hi, > > The case pthread_cond_init/1-2.c sometimes passed, but sometimes failed on my box. > > OS: RHEL6.1GA x86_64 > Memory: 4GB > CPU: Xeon E5506 2.13GHz, 4 cores > > When it failed, I got the following messages: > > # ./1-2.run-test > Test starting... > Timers option : 200809 > Clock Selection option : 200809 > Starting clock test > Data initialized successfully for CS test. > Sysconf for monotonix clock: 200809 > clock_settime succeeded > Monotonic clock : 200470.244301499 > Default clock : 1310609518.800609262 > Computed diff : 1310409048.556307763 > With monotonic smaller than default > Two threads are created and waiting. > About to change the default clock value. > Checking that both threads have timedout... > The thread was not woken when the clock was changed so as the timeout expired > Going to simulate this POSIX behavior... > Rechecking that both threads have timedout... > Null attribute cond var timed out > Default attribute cond var did not time out > Default clock was set back using monotonic clock as a reference > Default attribute cond var timedwait return value: 0 > Default attribute cond var exited with a timeout : no > Default attribute cond var had to be signaled : yes > Default attribute cond var exited as signaled : yes > Default attribute cond var spurious wakeups : 0 > Null attribute cond var timedwait return value: 110 > Null attribute cond var exited with a timeout : yes > Null attribute cond var had to be signaled : no > Null attribute cond var exited as signaled : no > Null attribute cond var spurious wakeups : 0 > Test ../../../conformance/interfaces/pthread_cond_init/1-2.c FAILED: The cond vars use different clocks. > > I think perhaps it has something to do with the scheduler. The case > calls sched_yield(), which calls __switch() directly in the kernel. > But maybe a very short time later, the main thread is scheduled again, > but not any of the child thread. As a result, sometimes the case passed, > and sometimes failed. I'm sorry. Here, I made a mistake. sched_yield() is a system call, which calls schedule() in kernel. It yields the current CPU to other tasks. So why did it sometimes pass, but sometimes fail? But when using sleep(1) instead of sched_yield(), it always passed? Does it have anything to do with multi cpus? > > I replace it with sleep(1), and I think 1 second is long enough > to ensure two children threads is scheduled. and now, the case > always passes. > > Here is the patch, please comment.:) > > > Signed-off-by: Tang Chen <tan...@cn...> > --- > .../conformance/interfaces/pthread_cond_init/1-2.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/testcases/open_posix_testsuite/conformance/interfaces/pthread_cond_init/1-2.c b/testcases/open_posix_testsuite/conformance/interfaces/pthread_cond_init/1-2.c > index 60ec77b..7f31ca2 100644 > --- a/testcases/open_posix_testsuite/conformance/interfaces/pthread_cond_init/1-2.c > +++ b/testcases/open_posix_testsuite/conformance/interfaces/pthread_cond_init/1-2.c > @@ -371,7 +371,7 @@ int do_cs_test(void) > if (ret != 0) { UNRESOLVED(ret, "Unable to unlock a mutex"); } > > /* Let the others threads run */ > - sched_yield(); > + sleep(1); > > #if VERBOSE > 1 > output("Checking that both threads have timedout...\n"); > @@ -636,4 +636,4 @@ int main(int argc, char * argv[]) > { FAILED("The cond vars use different clocks."); } > > PASSED; > -} > \ No newline at end of file > +} -- Best Regards, Tang chen -------------------------------------------------- Tang Chen Development Dept.I Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST) No.6 Wenzhu Road, Nanjing, 210012, China TEL: +86+25-86630566-8508 FUJITSU INTERNAL: 7998-8508 FAX: +86+25-83317685 EMail: tan...@cn... -------------------------------------------------- This communication is for use by the intended recipient(s) only and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not an intended recipient of this communication, you are hereby notified that any dissemination, distribution or copying hereof is strictly prohibited. If you have received this communication in error, please notify me by reply e-mail, permanently delete this communication from your system, and destroy any hard copies you may have printed |
From: Cyril H. <ch...@su...> - 2011-06-30 15:05:04
|
Hi! > I'm sorry. Here, I made a mistake. > sched_yield() is a system call, which calls schedule() in kernel. It yields > the current CPU to other tasks. > So why did it sometimes pass, but sometimes fail? But when using sleep(1) > instead of sched_yield(), it always passed? > Does it have anything to do with multi cpus? I've just commited patch to remove the test as after careful review, it turned out that there is no reasonable way how to test that two condition variables are initalized exactly same way. (same goes for 1-3 and 2-2). -- Cyril Hrubis ch...@su... |