[ofw] [PATCH] complib/user: fix timer race conditions

Fab Tillier ftillier at microsoft.com
Mon Jun 28 10:50:00 PDT 2010


Tzachi Dar wrote on Mon, 28 Jun 2010 at 10:46:37

> The simple solution is to create a thread and to use timeout options of
> waitforsingleoject. All other solutions are much more complicated than
> what one would think.

Why bother, just have opensm create a thread and do a sleep itself.  Having a timer abstraction that just uses a thread for each timer, while functional, isn't really a good abstraction.

-Fab

> 
> Thanks
> Tzachi
> 
>> -----Original Message-----
>> From: Hefty, Sean [mailto:sean.hefty at intel.com]
>> Sent: Monday, June 28, 2010 8:26 PM
>> To: Hefty, Sean; Tzachi Dar; Smith, Stan; Fab Tillier;
>> ofw at lists.openfabrics.org
>> Cc: Uri Habusha; Yevgeny Kliteynik
>> Subject: RE: [PATCH] complib/user: fix timer race conditions
>> 
>>> I don't follow their logic.  If the OS can't automatically clean up
> a
>> one-
>>> shot timer, then there's no way our abstraction can...  The timer APIs
>>> seem pretty weak, and the documentation vague at best.
>> 
>> I submitted a comment about the documentation.  I also threw together a
>> quick test to verify that without the call to DeleteTimerQueueTimer
>> that there is a memory leak.
>> 
>>> struct timer_osd
>>> {
>>> 	cl_timer_t *p_timer;
>>> 	HANDLE timer;
>>> };
>>> 
>>> in cl_timer_trim() and pass that to the timer callback.  The
> callback
>> calls
>>> DeleteTimerQueueTimer if it has not already been called for the
> timer
>> in
>>> question.
>> 
>> I'll update the patch to do something similar to this, to ensure that
>> we have matching Create-Delete calls and re-submit, unless someone sees
>> a simple solution.



More information about the ofw mailing list