On Thu, Jul 17, 2008 at 10:05 AM, John Baldwin <jhb@freebsd.org> wrote:
quoted text
> On Saturday 12 July 2008 07:11:26 pm Michael B Allen wrote:
>> Hi,
>>
>> Below is a semtimedop(2) implementation that I'm using for FreeBSD. I
>> was hoping someone could look it over and tell me if they think the
>> implementation is sound.
>>
>> The code seems to work ok but when stressing the FreeBSD build of my app
>> I have managed to provoke errors related to concurrency (usually when a
>> SIGALRM goes off). The Linux build works flawlessesly so I'm wondering
>> about this one critical function that is different.
>>
>> Do you think it would make any difference if I used
>> ITIMER_VIRTUAL / SIGVTALRM instead of ITIMER_REAL / SIGALRM?
>>
>> Or perhaps I should be using a different implementation entirely?
>
> What specific races are you seeing?  The timer is firing too early, too late?

It's very difficult to tell. I can only trigger the issue very
occasionally running my torture test such that any diagnostic logging
changes the results.

And at this point I'm not sure my semtimedop implementation is
responsible. I have not seen the issue since fixing the race pointed
out by Mikko (although I have not tried very hard to provoke it).

For now, I'm satisfied since I do not think the issue will be
triggered in the wild. I hate to use signals for anything but as much
as I try, there's just no other way to implement semtimedop within a
single largely self-contained function. In the future I will likely
use another process in the application that uses select(2) as an
"event service" to post on semaphores after a certain time period.
Unfortunately, right now, that service ultimately calls semtimedop so
I'll save it for a rainy day.

Although if you implemented semtimedop(2) into the FreeBSD API that
would work too :-)

Thanks,
Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"