Why implement a new locking mechanism when there is already one available in .\src\MISC\common\mutex.*?

Agree, Yuni::Mutex could be used instead. In such case I'll add a new class Yuni::MutexLockerEx that will include the m_bLocked member and additional methods Lock and Unlock - similar to CComCritSecLock.

There's already a Yuni::MutexLocker class. Why not use that one?

@MAPJe71, please look at the implementation of Yuni::MutexLocker and then re-read my previous comment :) This is because of the following line in CThreadSafeQueue::push :
lock.Unlock();
So it's kind of lock_guard with additional manual methods Lock and Unlock.

Dispite using an autolocker/lock-guard on a mutex you can still manually (un-)lock it e.g.

template <typename C>
class CThreadSafeQueue : protected std::list<C>
{
public:

	void push(C& c)
	{
		Yuni::MutexLocker lock(m_Mutex); //<-- auto lock (RAII)
		push_back( c );
		m_Mutex.unlock(); //<-- manual unlock

		if (!::ReleaseSemaphore(m_hSemaphore, 1, NULL))
		{
			// If the semaphore is full, then take back the entry.
			m_Mutex.lock(); //<-- manual lock
			pop_back();
			if (GetLastError() == ERROR_TOO_MANY_POSTS)
			{
				m_bOverflow = true;
			}
		}
	} //<-- auto unlock

	bool pop(C& c)
	{
		Yuni::MutexLocker lock(m_Mutex);

        // 
	}

protected:
	Yuni::Mutex m_Mutex;
};

@MAPJe71,
I bet you've already noticed what's wrong with that code.
Surely, it's this situation:

{
    Yuni::MutexLocker lock(m_Mutex); //<-- auto lock (RAII)
    m_Mutex.unlock(); //<-- manual unlock
} //<-- auto unlock - shit, unlocked twice!

Oooh, d#mn it you're right that won't work (as intended) 😁

@donho and @milipili could you extend the Yuni::MutexLocker class with manual un-/lock?
Would you consider a PR for libyuni?

I'd rather propose to have 2 classes: MutexLocker and MutexLockerEx, without inheritance.
Here is why:

1. MutexLockerEx will have an additional bool member variable (see the proposed CCriticalSectionLock implementation), which is simply not needed for a lightweight MutexLocker.
2. MutexLockerEx will have an additional argument in the constructor (see the proposed CCriticalSectionLock implementation), which is simply not needed for a lightweight MutexLocker.

OK, guys - no additional classes now. Just a little more thinking and a little bit more braces :)

Now I believe it's good enough.

@d0vgan additional benefit: building with mingw would be possible again, because ATL is not available there, see #4145 and there #2478 with patches to avoid ATL, see chcg@463bdc5#diff-5b536d07367d39b369aea9582ff0fe9d

with
std::unique_lock<std::mutex>
as replacement for
CComCritSecLock<CComAutoCriticalSection>

Wow, so I'm not the first one to propose this!
As for std::mutex, it's better with regards to C++ standard, however it has some overhead comparing to Critical Section (which is used by Yuni::Mutex).
Anyway, both solutions will work.

rebased + now everything in 1 commit

Come on, why these ATL things are still here?
"Entities are not to be multiplied without necessity"!

I used to think that it's me who is conservative and not fast - now I see I'm not alone :)

@MAPJe71 From my point of view and from my experience, unlocking a mutex in the middle of the code where it is supposed to be managed by the scope is far from a good idea. Like deleting some resource managed by unique_ptr. For this reason, it is unlikely that an unlock mecanism comes in libyuni, better fix the code with proper raii (but feel free to bring some particular use-case).

Regarding libyuni/mutex, this is historical reason as std::mutex didn't exist before as you can guess. As of now, as the official minimum version for n++ is 2015 (if not mistaken, would be better to switch to 2017 from my point of view, there is a better support for multithread and brings multiple fixes), I would recommend to replace yuni/mutex by its stl counterpart as there is no added value.

That's said, it is right here to use yuni/mutex here, for code consistency. That replacement has nothing to do with this MR and should be another one.

@d0vgan I would encourage you next time to use multiple commits as it changes different things.

@MAPJe71 Where did you find the snippet you posted regarding CThreadSafeQueue? I am surely missing something here as I can't find the unlock()

@donho For information, libyuni is going full C++17, so Yuni::Mutexshould disappear in the future (depending if users are still using it or not)

@milipili the snippet is from PowerEditor/src/WinControls/ReadDirectoryChanges/ThreadSafeQueue.h.

Ah yes right. Inheriting from std::list.... Just kill it with fire. Twice :)

@donho This class CThreadSafeQueue should die, or at least rewritten. No one must inherit from any stl container, as specified by the standard. Better use encapsulation instead of inheritance anyway.

ATL dependency is really annoying. Nice job :)

After some thinking, I think I vote for chcg's patch:
chcg/notepad-plus-plus@463bdc5#diff-5b536d07367d39b369aea9582ff0fe9d
It uses the standard STL's std::mutex - and it is better than relying on thirdparty's Yuni::MutexLocker, which additionally needs to be consireder to be updated.

@d0vgan: just to provide some aux. info, since I had the same fundamental problem as well. ATL/MFC is available with the Visual C++ Build Tools 2015. You can build Notepad++ easily that way.

@MIvanchev The main point to get ride of ATL I think is to be able to build this under mingw.

@MIvanchev The main point to get ride of ATL I think is to be able to build this under mingw.

Yes, I also think the mingw build should be restored. I wanted to raise awareness that the Build Tools include ATL/MFC, because I wasted 2 days trying to figure out things... =)

@d0vgan Sorry for the late review. Could you solve the conflict please?
Also could you use lock_guard instead please?

@d0vgan Never mind, I will take in charge of it. Thank you for the PR.