0

I'm writing a (very small) webserver in C language on Windows. I need exclusive lock file both on reading and writing files, i've read msdn documentation about locking etc. and I've found the function LockFileEx with the OVERLAPPED structure and an Event hEvent, I read also about how they work but the question is: - In a web server we have lots of files, when a thread locks for example the file "test.txt"(exclusive lock) because for there was a request of this file, how can I synchronize another thread that wants to get the lock on the same file?

thank you.

Ander Biguri
  • 35,140
  • 11
  • 74
  • 120
user2199646
  • 1
  • 1

1 Answers1

0

Take a look at the use of mutex objects. They should solve that problem for you.

Threads that need access to the lock file can request a lock for it and be queued. When the current thread is done, it releases its lock and the next requesting thread is granted the lock.

K Scott Piel
  • 4,320
  • 14
  • 19
  • ok, but in this way i need a mutex for each file that threads wants to open? And if is it, so i need to store all mutex in memory? right? – user2199646 Mar 22 '13 at 16:13
  • Well... you shouldn't need a lock in the first place unless the file is writable or subject to alteration while the server is reading it for delivery to the client. Otherwise, there's no reason to ask for locks on a read-only file. That said, yes and no... it would depend on the application. You could use a mutex per directory, per service or any number of other optimizations, but that's driven by design and application. – K Scott Piel Mar 22 '13 at 16:21
  • yes, the problem is that the specific require exclusive acces on read/write for every files. – user2199646 Mar 22 '13 at 16:39
  • Okay... is this a straight C app, or a C++ app? If you are using C++, I would suggest using the STL::map container to manage mutexes... key on the file name, value being the mutex. Otherwise, use a similar C construct or container lib. – K Scott Piel Mar 22 '13 at 16:43
  • this is a straight C console app – user2199646 Mar 22 '13 at 16:50
  • Set up a linked list of files being requested containing the file name and a mutex. If the file is in the list, block on the mutex for that file, if it is not in the list, create a mutex and append it to the list. If the last requestor has released the file, remove it from the list. – K Scott Piel Mar 22 '13 at 16:56
  • ok, i've tried to implement the link list but now i have a problem...how can i know if a thread is the last to have requested the mutex? – user2199646 Mar 24 '13 at 18:01
  • Because there would be no more entries in the link list. It would be the last node on this. Or, more precisely, listEntry->next would be NULL. – K Scott Piel Mar 24 '13 at 19:05
  • ok.. the question was: how can i know if a thread is the last one to have requested the mutex for "file1.txt"(for example)? i'm worrying about what happens in this scenario: there is a thread "A" which is the first to obtain the "mutex1" for the "file1.txt". Now a thread "B" wants "file1.txt" too, so it looks in the list and finds that file. Now thread "B" blocks on "mutex1"(WaitForSingleObject). If thread "A" has finished its job and now, how thread A knows that there is thread "B" waiting on mutex? Probably i did not understand the structure that you said. thank you – user2199646 Mar 25 '13 at 01:39
  • The structure is a list of the files that the system is asking to load and a mutex for each file that has been requested. The mutex locking system itself can worry about who gets the file next. You can tell that you're the last requestor by there being no pending locks. But you really don't *have* to remove it from the list, you could just as well leave it if it's likely there will be a new requestor soon. – K Scott Piel Mar 25 '13 at 01:49
  • i'm worrying about race condition: if thread A finish how it knows that there is no pending request on the "file1.txt"? if the node of the list will be deleted what about waiting threads? and if come another thread which claim the same file? it could not see that other threads were waiting for it... so it will create a new node in the linked list and the result is impredicible... right? – user2199646 Mar 25 '13 at 02:16
  • There is the outlier condition that a thread requests a lock between the time that the current thread checked to see there was a pending request and removed the list entry. If there's no fear of the list growing without bounds, then just leave it. Create the entry on the first request and leave it until the application exits. You might consider using a hash lookup though if the list is going to get big, otherwise, as the list grows it will degrade performance. – K Scott Piel Mar 25 '13 at 11:33