[Ace-users] Re: [ace-bugs] Bug with ACE_OS::sema_wait (ACE_sema_t *s, ACE_Time_Value &tv) when ACE_USES_WINCE_SEMA_SIMULATION is defined

[Steve Huston]

Hi Shaolong,

Thank you for the PROBLEM-REPORT-FORM. Can you please try the below
fix and let me know how this goes?

Thanks,
-Steve

Index: OS_NS_Thread.inl
===================================================================
--- OS_NS_Thread.inl	(revision 78573)
+++ OS_NS_Thread.inl	(working copy)
@@ -2352,12 +2352,21 @@
   // timeout.  In that case, we'll need to restart the process with
   // updated timeout value.
 
-  // <tv> is an absolute time
-  ACE_Time_Value relative_time = tv - ACE_OS::gettimeofday ();
+  // tv is an absolute time, but we need relative to work with the
Windows
+  // API. Also, some users have become accustomed to using a 0 time
value
+  // as a shortcut for "now", which works on non-Windows because 0 is
+  // always earlier than now. However, the need to convert to
relative time
+  // means we need to watch out for this case.
+  ACE_Time_Value end_time = tv;
+  if (tv == ACE_Time_Value::zero)
+    end_time = ACE_OS::gettimeofday ();
+  ACE_Time_Value relative_time = end_time - ACE_OS::gettimeofday ();
   int result = -1;
 
-  // While we are not timeout yet.
-  while (relative_time > ACE_Time_Value::zero)
+  // While we are not timeout yet. >= 0 will let this go through once
+  // and if not able to get the object, it should hit WAIT_TIMEOUT
+  // right away.
+  while (relative_time >= ACE_Time_Value::zero)
     {
       // Wait for our turn to get the object.
       switch (::WaitForSingleObject (s->count_nonzero_,
relative_time.msec ()))
@@ -2402,7 +2411,7 @@
 
       // Haven't been able to get the semaphore yet, update the
       // timeout value to reflect the remaining time we want to wait.
-      relative_time = tv - ACE_OS::gettimeofday ();
+      relative_time = end_time - ACE_OS::gettimeofday ();
     }
 
   // We have timed out.

--
Steve Huston, Riverace Corporation
Would you like ACE to run great on your platform?
See http://www.riverace.com/sponsor.htm

-----Original Message-----
From: ace-bugs-bounces at cse.wustl.edu
[mailto:ace-bugs-bounces at cse.wustl.edu] On Behalf Of shaolong xiang
Sent: Tuesday, May 22, 2007 1:02 AM
To: ace-bugs at cse.wustl.edu
Subject: [ace-bugs] Bug with ACE_OS::sema_wait (ACE_sema_t
*s,ACE_Time_Value &tv) when ACE_USES_WINCE_SEMA_SIMULATION is defined


HOST MACHINE:ArmVi and Windows Mobile 5.0: WINSOCK 2 

    THE $ACE_ROOT/ace/win32- config.h 

    AREA/CLASS/EXAMPLE AFFECTED: 
ACE_OS::sema_wait (ACE_sema_t *s, ACE_Time_Value &tv) is bugged when 
WINCE is defined 
Semaphore simulation might be inaccurate. 

    DOES THE PROBLEM AFFECT: 
        EXECUTION? 
Application blocks in ACE_OS::sema_wait when wait time is specified as

ACE_Time_Value(0,0). 

    SYNOPSIS: 

>From what I understand, application should return immediately when 


tv, ie. wait time is specified as ACE_Time_Value(0,0). 
This happens in the case when !defined ACE_USES_WINCE_SEMA_SIMULATION 
because of the check below 
  if (tv.sec () == 0 && tv.usec () == 0) 
    msec_timeout = 0; // Do a "poll." 
However, such a check is missing when defined 
ACE_USES_WINCE_SEMA_SIMULATION. 
Function goes straight on to calculate relative time. 
  ACE_Time_Value relative_time = tv - ACE_OS::gettimeofday (); 

relative_time becomes negative because we have 0 - timeofday. 
Even though it is negative, 
  while (relative_time > ACE_Time_Value::zero) is true. 
Then the function blocks for the negative waiting time which seems 
like forever. 

    SAMPLE FIX/WORKAROUND: 
Do a check, 
if (tv.sec () == 0 && tv.usec () == 0) relative_time = 
ACE_Time_Value::zero.