Re : System V Semaphores (Needs Reply Urgently)

Re : System V Semaphores (Needs Reply Urgently)

Post by Irene Se » Mon, 07 Aug 1995 04:00:00



Hi!
Currently, I faced some difficulty dealing with the above semaphores.
There are three processes that are trying to access a common resource. The access of this common resource is controlled with the use of System V IPC-Semaphores (with undo facility).

The problem that I faced is as follows
Process 1 is currently accessing the common resource say at 00:00:00 (semphore is locked). Process 2 at 00:00:45 is trying to access the resource followed by Process 3 at 0:02:50 is trying to access too. The problem is why Process 3 get the resource instead of Process 2 at 0:04:10. On top of that, when Process 1 retries, it manages to get the resource back at 0:05:45. Process 2 only manage to get the resource at 0:07:00.

The above  processes are running in the same priority (not set).
The system that the processes are run on is DEC ALPHA OSF/3

I have tried using the scheduler to set a higher priority for process 2 but results in the kernel allocating too much timeslice for process 2 and this is undesirable.

My questions are :

1. Why Process 3 get the resource instead of Process 2?
2. Isn't it the access of semaphores FIFO
3. If Process 2 loses its timeslice, why it only manage to get it back after    7 minutes?
4. Is there any way that every process has a equal chance to access the resource? That is, the first to request will be the first to get it.

Urgently requires some advice!!!

Thanks

Irene


 
 
 

Re : System V Semaphores (Needs Reply Urgently)

Post by Mikhail Estr » Tue, 08 Aug 1995 04:00:00


: Hi!
: Currently, I faced some difficulty dealing with the above semaphores.
: There are three processes that are trying to access a common resource. The access of this common resource is controlled with the use of System V IPC-Semaphores (with undo facility).

: The problem that I faced is as follows
: Process 1 is currently accessing the common resource say at 00:00:00 (semphore is locked). Process 2 at 00:00:45 is trying to access the resource followed by Process 3 at 0:02:50 is trying to access too. The problem is why Process 3 get the resource instead of Process 2 at 0:04:10. On top of that, when Process 1 retries, it manages to get the resource back at 0:05:45. Process 2 only manage to get the resource at 0:07:00.

Do you use the same sem_op value for different processes when calling semop()
to obtain resource?

--

"All Men Play on Ten"
        - MANOWAR

 
 
 

Re : System V Semaphores (Needs Reply Urgently)

Post by Joern Rennec » Tue, 08 Aug 1995 04:00:00



>Hi!
>Currently, I faced some difficulty dealing with the above semaphores.
>There are three processes that are trying to access a common resource. The access of this common resource is controlled with the use of System V IPC-Semaphores (with undo facility).
>The problem that I faced is as follows
>Process 1 is currently accessing the common resource say at 00:00:00 (semphore is locked). Process 2 at 00:00:45 is trying to access the resource followed by Process 3 at 0:02:50 is trying to access too. The problem is why Process 3 get the resource instead of Process 2 at 0:04:10. On top of that, when Process 1 retries, it manages to get the resource back at 0:05:45. Process 2 only manage to get the resource at 0:07:00.
>The above  processes are running in the same priority (not set).
>The system that the processes are run on is DEC ALPHA OSF/3
>I have tried using the scheduler to set a higher priority for process 2 but results in the kernel allocating too much timeslice for process 2 and this is undesirable.
>My questions are :
>1. Why Process 3 get the resource instead of Process 2?
>2. Isn't it the access of semaphores FIFO
>3. If Process 2 loses its timeslice, why it only manage to get it back after    7 minutes?
>4. Is there any way that every process has a equal chance to access the resource? That is, the first to request will be the first to get it.
>Urgently requires some advice!!!

If you want a first-come, first-served behaviour, make this explicit: use
a fifo.
A process that wants access to the resource but doesn't get it imediately
stores its pid into the fifo.
When a process having the resource releases it, it reads from the fifo;
if the read suceeds, it signals the process with the just-read pid that
it can have the resource, without clearing the semaphore.

Of course you have to take care that there is no race condition that leaves
the fifo filled and the semaphore cleared.

One way to do is is to try again to set the semaphore after writing to the
fifo. If this suceeds, read from the fifo and signal the appropriate process.

Of course you can just leave the semaphore check before writing to the fifo
out, it is only useful if the resource is usually free and this case
should be speeded up.

        Joern Rennecke

 
 
 

1. Need a Posix semaphore timeout system

Hi all,

I work under HP-UX and Solaris with POSIX semaphores. I need an
unexisting API like "sem_wait" with a timeout. In fact, the "sem_wait"
and "sem_trywait" APIs are not sufficient because I would like my
processes to be blocked until a certain amount of time is passed. And I
see no timeout management in the POSIX APIs.

Am I bound to use a timer by calling "create_timer" and to manage the
send of a signal to the blocked process in order to exit the "sem_wait"
? And if such a procedure is mandatory, is somenone can show me quickly
how to handle the signal (or the correct manual entry) ?

Thanx for all,

O. Rey

2. Large Cache for Apache

3. Linux guru needed urgently for lucrative contract work.

4. X driver for remote computer via dialup?

5. SLIP....urgently need help

6. Multiple PCI Ethernet Cards

7. Urgently need help !!!!

8. Console on tty accessed from 2nd machine via null modem cable

9. Help (urgently) needed repairing filesystem (ext2)!

10. info needed urgently

11. Urgently needed: how to configure a Linux dummy interface

12. Help urgently needed: 3C509B card cannot detected correctly

13. Socket programming help needed urgently