| 1 |
On Tuesday 22 July 2003 19:07, Jeff Adams wrote: |
| 2 |
> Hello, |
| 3 |
> |
| 4 |
> I have a producer process that makes updates to shared memory. I need to |
| 5 |
> notify consumer processes (potentially multiple) as quickly as possible. |
| 6 |
> |
| 7 |
> What I am looking for is a fast "wake-up" mechanism and a synchronization |
| 8 |
> mechanism so that events are not lost. |
| 9 |
> |
| 10 |
> I'm currently using semaphores as the wake up mechanism. Question is this |
| 11 |
> the fastest way to do this without going into a tight loop (waste of |
| 12 |
> processor cycles)? |
| 13 |
> |
| 14 |
> I'd also have the issue of clients showing up asynchronously. If I just |
| 15 |
> use semaphores counts based on the number of clients I run the risk of |
| 16 |
> missing a client. Also if the clients process events too slowly then the |
| 17 |
> producer will keep incrementing the semaphore beyond the client count. |
| 18 |
> Then if one client is faster than the others it may get awakened multiple |
| 19 |
> times for the same event. |
| 20 |
> |
| 21 |
> Any suggestions? |
| 22 |
> |
| 23 |
|
| 24 |
You could use pipes as IPC. In that case you push a byte in the pipe at the |
| 25 |
moment you want the clients to wake up. This should make them me scheduled as |
| 26 |
soon as possible (in case they are locked waiting for the pipe). Another way |
| 27 |
could be to use signals. But if you give each process a semaphore that should |
| 28 |
also work. The only question is whether it is a problem if one process has a |
| 29 |
slightly higher chance to be first than the other processes. Normally it |
| 30 |
isn't. |
| 31 |
|
| 32 |
Paul |
| 33 |
|
| 34 |
-- |
| 35 |
Paul de Vrieze |
| 36 |
Researcher |
| 37 |
Mail: pauldv@××××××.nl |
| 38 |
Homepage: http://www.devrieze.net |
Archives