Unix Programming - semaphore/mutex to control aio

Author

semaphore/mutex to control aio

2006-07-12, 7:00 pm

Is it possible to use either a pthread_mutex_t or semaphore to limit
execution in a single process?

The situation is this:

Spawn multiple aio and wait notification via signal.
On signal, (in signal handler) attempt to calculate a time difference
between program start time and completion time of [current] aio.

Now, if a single signal was used for all aio calls this would be easy
as the handler would block duplicate signals. However, I am using a
seperate signal for _each_ aio which means that I am getting additional
signals during this calculation.

I've tried both mutex and semaphore approaches, but it seems that as
soon as the lock is set, the process hangs waiting for it to be unset
again (by an outside source). I assume that the lock is acquired for
the first signal, but execution is suspended upon the arrival of the
second signal due to the blocking call to either pthread_mutex_lock or
semop.

Is there a solution that avoids additional threads and/or a daemon?

Thanks in advance.

Maxim Yegorushkin

2006-07-14, 4:00 am

L7 wrote:

> Spawn multiple aio and wait notification via signal.
> On signal, (in signal handler) attempt to calculate a time difference
> between program start time and completion time of [current] aio.
>
> Now, if a single signal was used for all aio calls this would be easy
> as the handler would block duplicate signals. However, I am using a
> seperate signal for _each_ aio which means that I am getting additional
> signals during this calculation.
>
> I've tried both mutex and semaphore approaches, but it seems that as
> soon as the lock is set, the process hangs waiting for it to be unset
> again (by an outside source). I assume that the lock is acquired for
> the first signal, but execution is suspended upon the arrival of the
> second signal due to the blocking call to either pthread_mutex_lock or
> semop.

You could try using a recursive mutex. Although posix guaranties that
only sem_post is async-signal safe.

Another approach would be to do nothing more than writing to a pipe in
the signal handler and then read the other end of the pipe and process
elsewhere.

Sponsored Links