Mutex – WinAPI – library MetaTrader 5

Why this is necessary

Global variables, disk or memory-mapped files, important operating procedure are not a problem anymore!

If you use:

• calls to the same data from different experts
  
• work with other applications from MQL in general data
  
• your copiers work in various MT4-MT4 / MT4-MT5 / MT5-MT5 terminals (Hello, Urain 🙂
• or you just need to comply with exact operating procedures among different experts of one or different terminals,
  

you shall understand how important is that performed algorithms do not appeal to same data via different processes simultaneously. As it can result in unexpected effects: one process is writing, and the other one is reading and making some decision, and renewing these data at the same time.

In such a case if writing of data by first process hasn’t been finished it may lead to incorrect work of the second process, as a result the data may be damaged.

The solution

We use objects of Mutual Exclusion operating system, in other words Mutex.

How it works

The Mutex is very simple. We use a principle similar to the principle described in this article: locking a resource when an object is created, and deallocation of a resource when an object is removed.

Working with Mutex is implemented in two classes.

• The first class – CMutexSync – represents Mutex handle resource, which is created and deallocated by this class. An object of this class can be global and the one for the whole application.
• The second class – CMutexLock – is a locked object which awaits for deallocation and locks Mutex handle when created, and deallocates it when removed.

The fact is that the CMutexLock release the Mutex resource and deleted after the ‘}’. The necessary flexibility is achieved this way

//------------------------------------------------------------------    class CMutexSync
class CMutexSync
{
  HANDLE64 m_mutex; // descriptor of mutex being created

public:
        CMutexSync() { m_mutex=NULL; }
        virtual ~CMutexSync() { Destroy(); }
        bool Create(LPCTSTR name) { m_mutex=CreateMutexWX(0, false, name); return(m_mutex!=NULL); }
        void Destroy() { CloseHandleX(m_mutex); m_mutex=NULL; }
        HANDLE64 Get() const { return(m_mutex); }
};

//------------------------------------------------------------------    class CMutexLock
class CMutexLock
{
  HANDLE64 m_mutex; // descriptor of mutex being locked

public:
  CMutexLock(CMutexSync &m, DWORD dwWaitMsec) { m_mutex=m.Get(); const DWORD res=WaitForSingleObjectX(m_mutex, dwWaitMsec); } // capture mutex in the process of object construction
  ~CMutexLock() { ReleaseMutexX(m_mutex); } // deallocate mutex when object is removed
};

Due to the locking principle of Mutex makes the code nice and readable. It frees the code from WinAPI functions

Example

In this example we will synchronize operation of cycles of two scripts in two charts.

The first script performs some operations for too long (2 seconds in the example). The second script performs its operations in a rapid manner (0.2 second).

Our task is not to allow new iteration of the rapid script until the first script completes its current iteration.

input int sleep=200;

//------------------------------------------------------------------
void OnStart()
{
        Sleep(5000); // wait till the script is on the second chart
        CMutexSync sync; // the object of synchronization
        if (!sync.Create("Local\\test")) { Print(Symbol()+" MutexSync create ERROR!"); return; }
        Print(Symbol()+" MutexSync created OK! Sleep=", sleep);
        
        for (int i=0; i<10; i++)
        {
                CMutexLock lock(sync, (DWORD)INFINITE); // lock a piece in this brackets of the cycle // here waiting and locking of mutex happen
                Print(Symbol()+" lock scope"); Sleep(sleep);
        }
}

Result

32/64 Ready

The library works taking into account 32/64 bit count in a similar way to MemMap.

I wish you good luck and big profits!