Hi Bert,
> Not sure if this is related:
>
> But you do know that Windows has completely different file semantics than
> posix, don't you. You can just use the standard file locking to have proper
> locking between threads, which doesn't work on many other platforms. (A
> process is free to shoot itself in its foot there when it wants to write a
> file locked via a different handle on those platforms. Locks are per handle
> on Windows, per process on Posix)
>
> On Windows file access is already synchronized by the OS, so it is not
> necessary to apply your own layer again, just because you have to do the
> same thing on other platforms.
FSFS uses three different mutexes (namely, fs_write_lock, txn_current_lock and
txn_list_lock). Everything you've said applies to the first two of them. These
two mutexes are only required on POSIX and the reason for having them is the
difference between the file locking mechanism on Windows and on POSIX.
Attempting to lock an already locked file from another thread will block on
Windows, but will not block on POSIX, hence the need for a mutex.
The txn_list_lock mutex, however, is entirely different. It is completely
unrelated to the filesystem (handles, locks, etc.) and is required for
synchronizing access to the transaction list (fs_fs_shared_txn_data_t).
So, this is just a regular mutex that is required to work with a non thread safe
object. Currently it is conditionally disabled on Windows and doing so could
easily lead to nasty race conditions with multiple threads simultaneously
accessing the transaction list object (they could leave it and the free
transaction pointer in an invalid state).
It looks like this mutex was used on Windows during the [r879916, r1182459]
timeframe [1][2], but got erroneously disabled in r1182459 [2]. Also see
http://svn.haxx.se/dev/archive-2009-10/0162.shtml
[1] http://svn.apache.org/viewvc?view=revision&revision=r879916
[2] http://svn.apache.org/viewvc?view=revision&revision=r1182459
Regards,
Evgeny Kotkov
Received on 2014-02-17 10:45:57 CET