timeout requirement for semaphores

timeout requirement for semaphores

Post by Shawn Ji » Thu, 18 Apr 2002 06:20:08



I'm working on porting a device driver from VxWorks to Linux. VxWorks
provides a timeout mechanism for all semaphores, which means that the
process will give up if another process holds the semaphore which it
requires more than "timeout" ticks. But Linux right now doesn't have a
similar machnism for semaphores. The requirement on my driver is as follows.
When a process accesses one resource which is taken by another process, it
goes to sleep and waits until either that process releases the resource or
timeout occurs. Can this be implemented on Linux without any real-time layer
support, such as RTLinux or RTAI. Thank you.

- Shawn

 
 
 

timeout requirement for semaphores

Post by Norm Dresne » Thu, 18 Apr 2002 22:32:15



> I'm working on porting a device driver from VxWorks to Linux. VxWorks
> provides a timeout mechanism for all semaphores, which means that the
> process will give up if another process holds the semaphore which it
> requires more than "timeout" ticks. But Linux right now doesn't have a
> similar machnism for semaphores. The requirement on my driver is as
follows.
> When a process accesses one resource which is taken by another process,
it
> goes to sleep and waits until either that process releases the resource
or
> timeout occurs. Can this be implemented on Linux without any real-time
layer
> support, such as RTLinux or RTAI. Thank you.

    Well .. sort of.   At the risk of starting a flame-war about
non-portable coding: what I've done in similar situations is to create,
within the same loadable module, a kernel timer task that gets called at a
time it specifies (resolution is, naturally, in jiffies) and if the task it
supervises is still waiting on the semaphore, it terminates it (and
restarts another instance so there is continuity).  It's not neat, but it
can be made to work.   Also, if you don't have microsecond response
requirements, you can use a once-per-jiffy (10 ms) kernel timer to check
for conditions instead of a brute-force wait on semaphore.

        Norm

 
 
 

timeout requirement for semaphores

Post by Shawn Ji » Fri, 19 Apr 2002 11:03:42


Quote:>     Well .. sort of.   At the risk of starting a flame-war about
> non-portable coding: what I've done in similar situations is to create,
> within the same loadable module, a kernel timer task that gets called at a
> time it specifies (resolution is, naturally, in jiffies) and if the task
it
> supervises is still waiting on the semaphore, it terminates it (and
> restarts another instance so there is continuity).  It's not neat, but it

Huh...how to check if a task is waiting on a semaphore?

Quote:> can be made to work.   Also, if you don't have microsecond response
> requirements, you can use a once-per-jiffy (10 ms) kernel timer to check
> for conditions instead of a brute-force wait on semaphore.

Kernel timer lists are polled about 100 times per second, which is too slow
in my case. Responses should be returned in 1 millisecond.

The timer queue may be a better choice? You're guaranteed that the queue
will run at next clock tick.

Shawn.

 
 
 

1. semaphore timeout

Hello,

Is there a way to specify a time out in msecs, that a semop operation will
last? I.e. I want semop to try for x msecs to get a semaphore, and afterthat
if it wasn;t succesful to exit.

Thanks,
MrZammler

2. Transparent Proxy - Squid & IPChains

3. Timeout on semaphores (in kernel context)

4. Newbie Modem Question

5. 2.5.49 - semaphore operations with timeouts

6. 2 ISP IP Masq works only with 1

7. timeout a semaphore

8. KDE wont start!!!

9. timeout on semaphore

10. : Semaphore with Timeout?

11. timeout a semaphore

12. timeout semaphore

13. Need a Posix semaphore timeout system