| 1 |
paul has two good ideas and i'd encourage signals. this is the type of |
| 2 |
thing they exist for! signals are definately not the "fastest" method |
| 3 |
of ipc because of the os stuff they invoke, but they are the most |
| 4 |
flexible IMO and won't waste cpu cycles because the processes can just |
| 5 |
"wait" untill they see the appropriate signal (then you have signal |
| 6 |
processing overhead, but thats probobly minor compared to scheduling a |
| 7 |
process to loop indefinately on a semaphore) |
| 8 |
|
| 9 |
just another 2 cents ;) |
| 10 |
dave |
| 11 |
|
| 12 |
On Tue, 2003-07-22 at 12:30, Paul de Vrieze wrote: |
| 13 |
> On Tuesday 22 July 2003 19:07, Jeff Adams wrote: |
| 14 |
> > Hello, |
| 15 |
> > |
| 16 |
> > I have a producer process that makes updates to shared memory. I need to |
| 17 |
> > notify consumer processes (potentially multiple) as quickly as possible. |
| 18 |
> > |
| 19 |
> > What I am looking for is a fast "wake-up" mechanism and a synchronization |
| 20 |
> > mechanism so that events are not lost. |
| 21 |
> > |
| 22 |
> > I'm currently using semaphores as the wake up mechanism. Question is this |
| 23 |
> > the fastest way to do this without going into a tight loop (waste of |
| 24 |
> > processor cycles)? |
| 25 |
> > |
| 26 |
> > I'd also have the issue of clients showing up asynchronously. If I just |
| 27 |
> > use semaphores counts based on the number of clients I run the risk of |
| 28 |
> > missing a client. Also if the clients process events too slowly then the |
| 29 |
> > producer will keep incrementing the semaphore beyond the client count. |
| 30 |
> > Then if one client is faster than the others it may get awakened multiple |
| 31 |
> > times for the same event. |
| 32 |
> > |
| 33 |
> > Any suggestions? |
| 34 |
> > |
| 35 |
> |
| 36 |
> You could use pipes as IPC. In that case you push a byte in the pipe at the |
| 37 |
> moment you want the clients to wake up. This should make them me scheduled as |
| 38 |
> soon as possible (in case they are locked waiting for the pipe). Another way |
| 39 |
> could be to use signals. But if you give each process a semaphore that should |
| 40 |
> also work. The only question is whether it is a problem if one process has a |
| 41 |
> slightly higher chance to be first than the other processes. Normally it |
| 42 |
> isn't. |
| 43 |
> |
| 44 |
> Paul |
| 45 |
-- |
| 46 |
Dave Nellans |
| 47 |
http://lucy.wox.org/~dnellans/ |
| 48 |
dnellans@×××××××.edu |
Archives