Date: Thu, 17 Jul 2008 20:15:11 -0400 From: John Baldwin <jhb@freebsd.org> To: "Michael B Allen" <ioplex@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Pls sanity check my semtimedop(2) implementation Message-ID: <200807172015.11460.jhb@freebsd.org> In-Reply-To: <78c6bd860807171042o54627c78nfcc0c19717b75f1e@mail.gmail.com> References: <78c6bd860807121611w4f6ab44brbebfffea9929682a@mail.gmail.com> <200807171005.53148.jhb@freebsd.org> <78c6bd860807171042o54627c78nfcc0c19717b75f1e@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 17 July 2008 01:42:31 pm Michael B Allen wrote: > On Thu, Jul 17, 2008 at 10:05 AM, John Baldwin <jhb@freebsd.org> wrote: > > 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 :-) POSIX semaphores (sem_open(3), sem_create(3), etc.) do have a sem_timedwait(3). However, POSIX semaphores have several bugs in 6.x and 7.x (they should work a lot better in 8). If you want I can give you a patch for 6.x or 7.x that backports the 8.x POSIX semaphores. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200807172015.11460.jhb>