4 ms·
The issue is the contention caused by all the processes waiting on file IO behind the lock, not the locking
by altano 10y ago
The issue is the contention caused by all the processes waiting on file IO behind the lock, not the locking
- danbruc 10y agoIf I/O were the bottleneck then that would be the case with or without a lock, wouldn't it?
- altano 10y agoIt depends on what has to wait for the IO to complete. ETW, for example, is a Windows-wide event framework and it would be untenable for everything using it to wait on the file IO of everything else making use of it. So, it has a solution that makes use of locks but nothing ever has to wait on file IO. File IO is always expensive, the trick is always in how you work around that.
- caf 10y agoYou don't actually need to hold the lock while doing I/O - just while allocating yourself a region of the file that's yours to exclusively write to (eg. by opening without O_APPEND and instead using pwrite(2) to write at a specific offset).