Changeset 99704 in vbox

Timestamp:

May 9, 2023 5:01:36 PM (19 months ago)

Author:

vboxsync

Message:

Runtime/testcase/tstRTSemEvent: test1() queues up two threads behind a
condition variable and then sends a signal to the condition variable and
verifies that the first thread queued was awakened. This fails on
Solaris since the order in which multiple threads blocked on a condition
variable are awakened is unspecified in the default scheduling class
(SCHED_OTHER). Fixed by simplifying the test for Solaris systems to
simply send two signals and then check that both of the waiting threads
have been awakened.

File:

• trunk/src/VBox/Runtime/testcase/tstRTSemEvent.cpp (modified) (3 diffs)

trunk/src/VBox/Runtime/testcase/tstRTSemEvent.cpp

@@ -166 +166 @@
 static void test1(void)
 {
-    RTTestISub("Three threads");
+    RTTestISub("Two threads");
 
     /*
@@ -185 +185 @@
     RTThreadSleep(256);
 
+#if defined(RT_OS_SOLARIS)
+    /*
+     * The Single UNIX Specification v2 states: "If more than one thread is blocked on a
+     * condition variable, the scheduling policy determines the order in which threads
+     * are unblocked."  On Solaris, the default scheduling policy, SCHED_OTHER, does not
+     * specify the order in which multiple threads blocked on a condition variable are
+     * awakened.  Thus we can't guarantee which thread will wake up when the condition
+     * variable is signalled so instead of verifying the order of thread wakeup we
+     * simply verify that two signals wake both threads.
+     */
+    /* Signal twice to wake up both threads */
+    RTTESTI_CHECK_RC(RTSemEventSignal(hSem), VINF_SUCCESS);
+    RTThreadSleep(256);
+    RTTESTI_CHECK_RC(RTSemEventSignal(hSem), VINF_SUCCESS);
+
+    RTTESTI_CHECK_RC(RTThreadWait(hThread1, 5000, NULL), VINF_SUCCESS);
+    RTTESTI_CHECK_RC(RTThreadWait(hThread2, 5000, NULL), VINF_SUCCESS);
+#else
+    /*
+     * The Linux sched(7) man page states: "SCHED_OTHER is the standard Linux
+     * time-sharing scheduler ... the thread chosen to run is based on a dynamic
+     * priority that ... is based on the nice value and is increased for each time
+     * quantum the thread is ready to run, but denied to run by the scheduler." This
+     * means that in practice the thread blocked longest on the condition variable will
+     * be awakened first and thus we can verify the ordering below.  FreeBSD and macOS
+     * don't seem to document their implementations for this scenario but empirically
+     * they behave similar to Linux.
+     */
     /* Signal once, hopefully waking up thread1: */
     RTTESTI_CHECK_RC(RTSemEventSignal(hSem), VINF_SUCCESS);
@@ -192 +220 @@
     RTTESTI_CHECK_RC(RTSemEventSignal(hSem), VINF_SUCCESS);
     RTTESTI_CHECK_RC(RTThreadWait(hThread2, 5000, NULL), VINF_SUCCESS);
+#endif
 
     RTTESTI_CHECK_RC(RTSemEventDestroy(hSem), VINF_SUCCESS);