Hello all,

Please, could someone give an advice or reference about the following
subject:

I've several processes that shares resources. The handling of one of
them is taken as a critical area, protected using UNIX semaphores
(semget, semop, semctl).

The problem is how to protect the system and skip a deadlock if one
process crash when inside the critical area. That is:
a) the process changes the sempahore to "red" and entries to the
critical area.
b) the process crashes. The semaphore becames "red" for ever.

Thanks a lot for the help.


(Note: my initial test has been done in Linux, but targets are Linux
and Solaris. Has Solaris any intrinsic implementation of secure
semphores that skips this situation?).

Secondary doubt:

Why the integer that is added/substarcted to the semaphore value can be
any integer?. I do not see any application of numbers different of +1
(to free semaphore) and -1 (to wait and set).

tmp123 <tmp123@menta.net> says:
> The problem is how to protect the system and skip a deadlock if one
> process crash when inside the critical area. That is:
> a) the process changes the sempahore to "red" and entries to the
> critical area.
> b) the process crashes. The semaphore becames "red" for ever.

What do you mean by "the process crashes"? Did you try to 
write your own signal handlers and prevent such situations?

-- 
Igor Pozgaj | ipozgaj at fly.srk.fer.hr
ICQ: 126002505  | IRC: @thunder (#linux@IdolNet)
PGP: 0xE673B5FD | http://fly.srk.fer.hr/~ipozgaj

"tmp123" <tmp123@menta.net> writes:

>Please, could someone give an advice or reference about the following
>subject:

>I've several processes that shares resources. The handling of one of
>them is taken as a critical area, protected using UNIX semaphores
>(semget, semop, semctl).

>The problem is how to protect the system and skip a deadlock if one
>process crash when inside the critical area. That is:
>a) the process changes the sempahore to "red" and entries to the
>critical area.
>b) the process crashes. The semaphore becames "red" for ever.

The process is in a critical section for a reason; you can use
SEM_UNDO to cause the semaphore operation to be undone on a crash,
however, you must make sure that you can recover from this state.

>Secondary doubt:

>Why the integer that is added/substarcted to the semaphore value can be
>any integer?. I do not see any application of numbers different of +1
>(to free semaphore) and -1 (to wait and set).

You can think of a producer consumer situation with multiple consumers.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

On 24 Jun 2005 04:33:29 -0700, "tmp123" <tmp123@menta.net> wrote:

>The problem is how to protect the system and skip a deadlock if one
>process crash when inside the critical area. That is:
>a) the process changes the sempahore to "red" and entries to the
>critical area.
>b) the process crashes. The semaphore becames "red" for ever.

Fix your code so that it does not crash within the critical section !

Long answer: 

As with kernel mode drivers, first test thoroughly all parameters
supplied that they are valid i.e. supported non-contradictory) values
and that the pointer are realistic (non-NULL) and for kernel driver
also check that they are accessible (R/W) from the _caller's_ user
mode address space.

If you intend to do some dangerous operation, such as division, before
attempting the operation, make sure that the divisor is non-zero to
avoid any division-by-zero faults. Other "dangerous" operations should
be checked the same way, before attempting them.

Avoid calling such routines of which you do not have full control
(such as library routines). 

If this is not possible and you attempt to do something complex, such
accessing a disk file/network device from the critical section, a
better approach would be to use a separate process to handle the file
I/O or network accesses and the other processes send requests to this
process and include some timeout mechanism, if no response is received
(network down, communication process crashed etc.)

Paul
 

tmp123 wrote:
> Hello all,
>
> Please, could someone give an advice or reference about the following
> subject:
>
> I've several processes that shares resources. The handling of one of
> them is taken as a critical area, protected using UNIX semaphores
> (semget, semop, semctl).
>
> The problem is how to protect the system and skip a deadlock if one
> process crash when inside the critical area. That is:
> a) the process changes the sempahore to "red" and entries to the
> critical area.
> b) the process crashes. The semaphore becames "red" for ever.
>
> Thanks a lot for the help.
>
>
> (Note: my initial test has been done in Linux, but targets are Linux
> and Solaris. Has Solaris any intrinsic implementation of secure
> semphores that skips this situation?).
>
> Secondary doubt:
>
> Why the integer that is added/substarcted to the semaphore value can be
> any integer?. I do not see any application of numbers different of +1
> (to free semaphore) and -1 (to wait and set).

If you can, create a master process and all other processes
of interest as children of this process.

When a child process crashes the parent receives a signal.

Handle this signal, in the master process, determine what
the resources obtained by the child process were
(semaphores ...)

Call sem_post in the master process in order to free a
semaphore if it was obtained by the crashed process.

Casper H.S. Dik wrote:
> "tmp123" <tmp123@menta.net> writes:
>
> >Please, could someone give an advice or reference about the following
> >subject:
>
> >I've several processes that shares resources. The handling of one of
> >them is taken as a critical area, protected using UNIX semaphores
> >(semget, semop, semctl).
>
> >The problem is how to protect the system and skip a deadlock if one
> >process crash when inside the critical area. That is:
> >a) the process changes the sempahore to "red" and entries to the
> >critical area.
> >b) the process crashes. The semaphore becames "red" for ever.
>
> The process is in a critical section for a reason; you can use
> SEM_UNDO to cause the semaphore operation to be undone on a crash,
> however, you must make sure that you can recover from this state.
>
> >Secondary doubt:
>
> >Why the integer that is added/substarcted to the semaphore value can be
> >any integer?. I do not see any application of numbers different of +1
> >(to free semaphore) and -1 (to wait and set).
>
> You can think of a producer consumer situation with multiple consumers.
>
> Casper
> --
> Expressed in this posting are my opinions.  They are in no way related
> to opinions held by my employer, Sun Microsystems.
> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.

Hello,

First of all, thanks to you and all people that has answered in other
threads to this post. For the current stage of the project, the
SEM_UNDO seems a valid and practical solution.

Thanks again.