Dan, I ran into some similar issues a while back. When dealing with a lot of simultaneous users it is most beneficial to process the request as quickly as possible to free up resources. Rather than waiting for a lock to be released on the file, I would queue the information somewhere else and let the next thread that obtains a lock deal with the queued requests then deal with its own requests. This way the program would never sit there waiting for a lock release.
In my case, I just put the requests in a list maintained in a common memory area. In your case, you may just want to write out little files with an incrementing name that contains the modification request. When the next thread gets a lock, it would read in those little files if they exist, fold them into the main data file, delete the files, and then process any of its own reads and writes. This will keep all the read and write requests linear when they need to be. The format in which the requests are stored obviously have to be independent of the data file that they are going to change.
I suspect that you may have so many instances of a single program running because of that arbitrary delay. Say that one thread obtains a lock on the data file and another thread then sees that lock and goes into its 1 sec wait almost at the same time. If the first lock is released in .5 secs and and another thread comes requesting a fresh lock right after, it obtains the lock and then the one that was waiting for 1 sec will then still see a lock and wait once again. Threads will continually trip over themselves causing temporary deadlocks, which in turn will keep instances of the program running.
Just some ideas from one programmer to another.
|