Date: Fri, 18 Jul 2008 17:58:56 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Michael B Allen <ioplex@gmail.com> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Pls sanity check my semtimedop(2) implementation Message-ID: <20080718155856.GA96280@stack.nl> In-Reply-To: <78c6bd860807121611w4f6ab44brbebfffea9929682a@mail.gmail.com> References: <78c6bd860807121611w4f6ab44brbebfffea9929682a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jul 12, 2008 at 07:11:26PM -0400, Michael B Allen wrote: > 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. > [snip semtimedop implementation that uses SIGALRM and relies on EINTR] > 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. In your implementation, the SIGALRM signal may happen before you even call semop(2). If so, most likely the semop(2) will hang arbitrarily long. A somewhat dirty fix is to put a nonzero value into it_interval. This will ensure that if a signal is missed another one will be generated quickly. You might be able to fix this using setjmp/longjmp, but this is neither pretty nor efficient. Another dirty fix is to try non-blocking semop(2) several times with sleeps in between. > Do you think it would make any difference if I used > ITIMER_VIRTUAL / SIGVTALRM instead of ITIMER_REAL / SIGALRM? This does not fix the inherent problem. Also, given your use of signals in the first place, your application must be single threaded. This means the ITIMER_VIRTUAL timer does not run while semop(2) is waiting. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080718155856.GA96280>