About this article
This article is created using an automated workflow powered by generative AI. By verifying the primary sources for Linux flock and .NET Named Mutex, we compare how Linux and Windows prevent the same scheduled process from running twice under the same criteria.Verification Status: 🧪 Linux flock execution verified. Windows Mutex verified against official specifications.
Information Verification Baseline Date: October 5, 2026
In scheduled processes like cron, systemd timers, and the Windows Task Scheduler, a new execution may sometimes start before the previous one has finished. For tasks such as backups, file updates, and blog posting, duplicate execution causes redundant processing and race conditions.
The fundamental way to prevent this incident isexclusive locking.
- Running flock twice on Linux
- The state cannot be determined solely by the presence of a lock file
- Define a timeout if you are going to wait
- Named Mutexes can be used on Windows
- Local and Global are not the same
- Consider Mutexes that terminated abnormally as well
- Deadlocks can also occur with multiple locks
- In periodic processing, separate the lock acquisition from the success or failure of the main process.
- Commonalities between Linux and Windows
- Daily-Code-Samples
- Official Information
Running flock twice on Linux
Execute this in Terminal 1.
flock -n /tmp/papanda-demo.lock bash -c 'echo "LOCK取得"; sleep 10; echo "LOCK解除"'
Execute the same command from Terminal 2 within 10 seconds.-n specifies that execution terminates immediately without waiting if the lock cannot be acquired.
By overlapping two processes in this environment,we confirmed that the second process could not acquire the lock.
flowchart TD
A["処理A 起動"] --> B{"flock取得?"}
B -- Yes --> C["処理Aを実行"]
D["処理B 起動"] --> E{"同じflock取得?"}
E -- No --> F["二重実行せず終了"]
C --> G["処理終了・lock解放"]
The state cannot be determined solely by the presence of a lock file
/tmp/papanda-demo.lockWhen seeing a filename like this, it looks as though the file itself holds the lock state.
util-linux's flock handles locks on files, directories, or open file descriptors. Therefore,The existence of a filename is not the same as the current lock being held.
Before deciding in production that "the lock file remains so we should just delete it," verify the owning process and service status.
Define a timeout if you are going to wait
Instead of failing immediately, you can wait for a specified duration.
flock -w 10 /tmp/papanda-demo.lock bash -c 'echo "処理開始"; sleep 20; echo "処理終了"'
For scheduled tasks, determine whether to "give up immediately," "wait a few seconds," or "notify monitoring" when a lock cannot be acquired.
Named Mutexes can be used on Windows
The .NET System.Threading.Mutex is mutual exclusion control that can also be used for inter-process synchronization.
$mutex = [System.Threading.Mutex]::new(
$false,
"Local\PapandaLockDemo"
)
$locked = $mutex.WaitOne(0)
if ($locked) {
try {
Write-Host "[SUCCESS] LOCK取得"
Start-Sleep -Seconds 5
}
finally {
$mutex.ReleaseMutex()
$mutex.Dispose()
}
}
else {
Write-Host "[BLOCKED] 別プロセスが実行中"
$mutex.Dispose()
}
If you open two PowerShell instances and execute the second one while the first is waiting for 5 seconds, you can determine multiple instance execution based on whether the Mutex with the same name can be acquired.
This Windows-specific part has not been verified on real hardware, so it is not treated as actual measurement results.
Local and Global are not the same
In this tutorial material, Local\PapandaLockDemo is used.
For cross-session use cases, Global\ comes into play, but permissions and operational requirements also change. Decide first which processes you want to exclude from each other.
Consider Mutexes that terminated abnormally as well
In .NET, if the thread that owned the Mutex terminates without releasing it, the next acquiring side may throw AbandonedMutexException .
This indicates that the previous process may have ended prematurely. The design must include checks to ensure that the files or data being protected are not left in an inconsistent state.
Deadlocks can also occur with multiple locks
処理A: LOCK-1取得 → LOCK-2待ち 処理B: LOCK-2取得 → LOCK-1待ち
flowchart LR
A["処理A<br>LOCK-1保持"] --> B["LOCK-2待ち"]
C["処理B<br>LOCK-2保持"] --> D["LOCK-1待ち"]
B --> C
D --> A
The basics of mitigation are standardizing the acquisition order, reducing the holding time, setting timeouts, and avoiding the addition of unnecessary locks.
In periodic processing, separate the lock acquisition from the success or failure of the main process.
For backups,
起動 ↓ ロック取得 ↓ 取得できなければ「前回処理中」として終了 ↓ バックアップ実行 ↓ 結果確認 ↓ ロック解放
becomes as follows.
Acquiring a lock does not mean the backup was successful. Record the success or failure of the main process separately.
Commonalities between Linux and Windows
| Linux flock | Windows Named Mutex |
|---|---|
| Can exclude concurrent execution | Can exclude concurrent execution |
| Uses file/FD | OS named synchronization object |
-n / -w controls how to wait | WaitOne(timeout) controls how to wait |
| Do not determine the state based solely on the lock file name | Mutex acquisition alone does not guarantee the consistency of protected data |
Although the implementation methods differ, the design questions remain the same.Determine who you will contend with, whether to wait or give up if the lock cannot be acquired, and what to verify after an abnormal termination.is decided.
