Joe Wilson wrote:
Remember, that the operating system bug that is causing all the
multithreading grief is that file locks created by one thread
cannot be reliably removed or modified by a different thread.
You could have a single thread that exclusively performs file locking/unlocking.
This thread would wait on a threadsafe work queue (using a POSIX
condition variable mechanism) and execute file locking/unlocking tasks,
otherwise it would use zero CPU. Functions could be provided to put
file lock/unlock operations on to this work queue and wait for the result.
Such file locking/unlocking functions could be called safely and reliably
from any thread.
That sounds like good practice to me. When one discovers that a
particular function is flaky and variable between implementations, O/S's
and versions prudence requires that it be bypassed. In our Sqlite usage
we want platform independence and reliability and accordingly never rely
on file locking for synchronization.
A bonus of such an approach is simpler code and logic and better
execution efficiency.
JS
