| PLEX86 | ||
|
Is implementing a mutex in shared memory the best ideaHello, Briefly, here is a bug that I may be confronted with and told to spend some time on. There are several embedded "time critical" programs on different machines (SGI, and Linux PC's and mainframes) that communicate through a shared memory file to a server program The server is currently on a SGI system. But, any changes to the code should be accomplished, so that the source code is transportable to a Linux machine. All the processes run at the same speed, and were completely written by individuals where I work. Questions: (1) Explicitly, what instructions can I use to prevent all the clients from clobbering each other in their desire to use the single communication link? I.E: The big problem is sometimes these client programs overwrite the communication area at about the same time and thus the network hangs up! So, when the network becomes useless like this, I have to restart the server which is not a good thing since all previous data is gone. Is implementing a mutex in shared memory the best idea 357 It sounds to me as if your needs would be well served by a semaphore. semaphores have been... (2) Via a shared memory location (using the same shared memory file as above and memory mapping technique), could I define a mutex to guard the critical section of server code? Are there any problems in doing this (such as speed reduction), and explicitly how would I fix them? I have never implemented a mutex like this before. (3) Are there any other alternatives? (4) What are the advantages and disadvantages of any choice? (5) What is my best option? Help, Christopher Lusardi
|
||||
Is implementing a mutex in shared memory the best idea 357 Linux groups from Newsgroups The #1 Usenet Provider on the Internet
|
||||