Praveen S wrote: > Hi, > Its not reinventing wheels. I tried to put the problem statement in simple > words. Description of the platform and the problem may not be suitable here. > > Well i would not agree with the timeout. Library will run in context of the > application. A crash in application will mean the timer also exits. > Application can hold the lock indefinitely as long as it is active. Suppose > a application is playing a video file. It locks the video file. And just > before graceful exit it unlocks it. But if it crashes in the middle of play > the lock is still active. > > The device is programmed to unlock on reboot. We are to find a solution > where you can solve this. I could think of the following but it has a back > drop. > 1) A log file maintains the lock status and the PID of app having that lock > 2) New applications will check for the lock status, if unlocked will get the > lock and update the PID value. > 3) If its locked then it will check for the PID value and check if that PID > is alive. If not alive will forcefull unlock . > > The problem would be the OS will issue PID in round robin manner. Suppose > application will PID 1 terminates abnormally. The OS may assign a PID of 1 > to any new application which comes up. > > > Please help. > > TIA > Praveen
A timeout is a good idea. The timeout goes into the file as well (last updated). Your process that holds the lock updates the file regularly to keep the lock. If the last updated time was 15-30 seconds ago, it is a pretty safe bet the application died. What you really need is a named mutex managed by the OS. Does the OS offer mutexes or other IPC mechanisms? -- Thomas Hruska CubicleSoft President Ph: 517-803-4197 *NEW* MyTaskFocus 1.1 Get on task. Stay on task. http://www.CubicleSoft.com/MyTaskFocus/
