Re: Extended Prefetching using Asynchronous IO - proposal and patch

On 06/25/2014 09:20 PM, Claudio Freire wrote:
> On Tue, Jun 24, 2014 at 12:08 PM, John Lumby <johnlumby@hotmail.com> wrote:
>>> The question is, if you receive the notification of the I/O completion
>>> using a signal or a thread, is it safe to release the lwlock from the
>>> signal handler or a separate thread?
>>
>> In the forthcoming  new version of the patch that uses sigevent,
>> the originator locks a LWlock associated with that BAaiocb eXclusive,
>> and ,   when signalled,  in the signal handler it places that LWlock
>> on a process-local queue of LWlocks awaiting release.
>> (No, It cannot be safely released inside the signal handler or in a
>> separate thread).     Whenever the mainline passes a CHECK_INTERRUPTS macro
>> and at a few additional points in bufmgr,  the backend walks this process-local
>> queue and releases those LWlocks.    This is also done if the originator
>> itself issues a ReadBuffer,  which is the most frequent case in which it
>> is released.
>
> I suggest using a semaphore instead.
>
> Semaphores are supposed to be incremented/decremented from multiple
> threads or processes already. So, in theory, the callback itself
> should be able to do it.

LWLocks are implemented with semaphores, so if you can increment a 
semaphore in the signal handler / callback thread, then in theory you 
should be able to release a LWLock. You'll need some additional 
synchronization within the same process, to make sure you don't release 
a lock in signal handler while you're just doing the same thing in the 
main thread. I'm not sure I want to buy into the notion that 
LWLockRelease must be generally safe to call from a signal handler, but 
maybe it's possible to have a variant of it that is.

On Linux at least we use System V semaphores, which are (unsurpisingly) 
not listed as safe for using in a signal handler. See list 
Async-signal-safe functions in signal(7) man page. The function used to 
increment a POSIX semaphore, sem_post(), is in the list, however.

- Heikki