From 05f4e7360886e36b221ef5c3af4426625a3de686 Mon Sep 17 00:00:00 2001 From: Michael Lutz Date: Mon, 11 Mar 2019 00:45:39 +0100 Subject: Codechange: Replace custom mutex code with C++11 mutex'es. A conforming compiler with a valid -header is expected. Most parts of the code assume that locking a mutex will never fail unexpectedly, which is generally true on all common platforms that don't just pretend to be C++11. The use of condition variables in driver code is checked. --- src/gfx.cpp | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'src/gfx.cpp') diff --git a/src/gfx.cpp b/src/gfx.cpp index 72d3fcd67..b7e31a384 100644 --- a/src/gfx.cpp +++ b/src/gfx.cpp @@ -1308,8 +1308,8 @@ void DrawDirtyBlocks() if (HasModalProgress()) { /* We are generating the world, so release our rights to the map and * painting while we are waiting a bit. */ - _modal_progress_paint_mutex->EndCritical(); - _modal_progress_work_mutex->EndCritical(); + _modal_progress_paint_mutex.unlock(); + _modal_progress_work_mutex.unlock(); /* Wait a while and update _realtime_tick so we are given the rights */ if (!IsFirstModalProgressLoop()) CSleep(MODAL_PROGRESS_REDRAW_TIMEOUT); @@ -1317,9 +1317,9 @@ void DrawDirtyBlocks() /* Modal progress thread may need blitter access while we are waiting for it. */ VideoDriver::GetInstance()->ReleaseBlitterLock(); - _modal_progress_paint_mutex->BeginCritical(); + _modal_progress_paint_mutex.lock(); VideoDriver::GetInstance()->AcquireBlitterLock(); - _modal_progress_work_mutex->BeginCritical(); + _modal_progress_work_mutex.lock(); /* When we ended with the modal progress, do not draw the blocks. * Simply let the next run do so, otherwise we would be loading -- cgit v1.2.3-54-g00ecf