#5986 closed defect (fixed)
Bad performance of CPLAcquireMutex() on Windows
| Reported by: | Even Rouault | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.0.0 |
| Component: | default | Version: | unspecified |
| Severity: | normal | Keywords: | |
| Cc: |
Description
CPLAcquireMutex() in the dfWaitInSeconds > 0.0 case does not perform well if the critical section is already hold by another thread.
This is due to the sleep of 125 ms which can be triggered easily on high contention scenarios. In practice dfWaitInSeconds is almost always set to 1000 to mean "infinite", so in that case we can just call EnterCriticalSection() that will have lower latency than TryEnterCriticalSection() + Sleep(). And in other cases reduce the sleep to 10 ms.
Change History (3)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
| Milestone: | → 2.0 |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
trunk r29302,29303, branches/2.0 r29304 (post RC0) "CPLAcquireMutex(): improve performance on Windows (#5986)"