Introduction
This article shows how to code a synchronized statement in C++ that works in a similar way to Java. The target of this code is to make a piece of code like the following, compilable and executable in C++:
synchronized(myMutex)
{
}
The Mutex class
The following piece of code presents a mutex class with lock/unlock semantics (common in many libraries):
class Mutex
{
public:
Mutex()
{
InitializeCriticalSection(&m_criticalSection);
}
~Mutex()
{
DeleteCriticalSection(&m_criticalSection);
}
void lock()
{
EnterCriticalSection(&m_criticalSection);
}
void unlock()
{
LeaveCriticalSection(&m_criticalSection);
}
private:
CRITICAL_SECTION m_criticalSection;
};
There is nothing particularly special for the above class:
- it initializes the critical section upon construction,
- it deletes the critical section,
- the method
lock() locks the critical section, and
- the method
unlock() unlocks the critical section.
We are going to use critical sections, but any synchronization primitive applies.
The Lock class
In order to be consistent with the C++ established code practices, we need a special class for implementing the RAII (Resource Acquisition Is Initialisation) pattern. The following piece of code shows such a class:
class Lock
{
public:
Lock(Mutex &mutex) : m_mutex(mutex), m_locked(true)
{
mutex.lock();
}
~Lock()
{
m_mutex.unlock();
}
operator bool () const
{
return m_locked;
}
void setUnlock()
{
m_locked = false;
}
private:
Mutex &m_mutex;
bool m_locked;
};
Things to note for this class:
- it locks the mutex upon construction, and
- it unlocks the mutex upon destruction.
Using the above class is pretty straightforward:
Mutex mutex1;
...
Lock lock1(mutex1);
The "synchronized" macro
The synchronized statement can be coded as a macro like this:
#define synchronized(M) for(Lock M##_lock = M; M##_lock; M##_lock.setUnlock())
where, the parameter M is the mutex variable to use for locking.
Example of using the "synchronized" macro
The following piece of code shows how to use the synchronized macro: it coordinates two threads that print the alphabet in the standard output. Without synchronization, the output is not correct:
int thread_count = 0;
Mutex mutex1;
DWORD CALLBACK thread_proc(LPVOID params)
{
for(int i = 0; i < 10; ++i)
{
synchronized(mutex1)
{
for(char c = 'A'; c <= 'Z'; ++c)
{
cout << c;
}
cout << endl;
}
}
thread_count--;
return 0;
}
int main()
{
thread_count = 2;
CreateThread(0, 0, thread_proc, 0, 0, 0);
CreateThread(0, 0, thread_proc, 0, 0, 0);
while (thread_count) Sleep(0);
getchar();
return 0;
}
How it works
The macro exploits the nature of the for statement of C++ to do the following (in the presented order):
- initialization part: a local lock variable is defined that locks the given mutex; the lock variable contains an internal flag which is set to true.
- test part: the lock variable is tested and found to be true: the code inside the loop is executed.
- increment part: the lock variable's internal flag is set to false.
- test part: the lock variable is tested and found to be false: the loop exits.
- exit part: the lock variable is destroyed, unlocking the mutex.
Advantages over classic RAII
Using this way to code RAII has some advantages over the traditional method:
- it makes the code more readable,
- it helps avoiding declaration of lock variables, and
- it ties the code to be synchronized with the synchronization scope.
Notes
The synchronized macro is exception-safe, since it unlocks its mutex upon destruction.
|
|
 |
 | Here is my version.
pedro.alves | 9:02 20 Dec '05 |
|
|
I had made this too some time ago.
My version is easily extendable. Here it goes:
syncronized.h -----------------------
#ifndef SYNCHRONIZED_H
#define SYNCHRONIZED_H
/*
make a RAII wrapper class to your synch object, and
define a make_synchronizer(T& m) method.
example for Qt's QMutex:
#include "syncronized.h"
struct synch_QMutex : public Synchronizer
{
synch_QMutex(::QMutex& m) : m_(&m)
{
m_.lock();
}
~synch_QMutex()
{
m_.unlock();
}
::QMutex m_;
};
inline synch_QMutex make_synchronizer(::QMutex& m)
{
return synch_QMutex(m);
}
...
and then:
void test()
{
QMutex mutex;
synchronized(mutex)
{
...
}
}
*/
namespace synchronizer {
struct Synchronizer
{
Synchronizer() : lock(0) {}
mutable int lock;
};
}
// uses ScopeGuard trick.
// const reference to temp has life extended.
#define synchronized(X) \
for (synchronizer::Synchronizer const &__lockable__ \
= synchronizer::make_synchronizer(X); \
!__lockable__.lock; \
__lockable__.lock++)
#endif
-----------------------
What do you think?
Pedro Alves
|
|
|
|
|
|
|
Blah, bug/typo in the comments!
replace:
::QMutex m_;
with:
::QMutex& m_;
around line 24 in file syncronized.h
Cheers,
Pedro Alves
|
|
|
|
|
|
|
Replace:
#define synchronized(X) \
for (synchronizer::Synchronizer const &__lockable__ \
= synchronizer::make_synchronizer(X); \
!__lockable__.lock; \
__lockable__.lock++)
with:
#define synchronized(X) \
if (0) else for (synchronizer::Synchronizer const &__lockable__ \
= synchronizer::make_synchronizer(X); \
!__lockable__.lock; \
__lockable__.lock++)
for VS6 compatibily (untested)
Cheers,
Pedro Alves
|
|
|
|
|
| C++ is not Java ... It's better
[Deep]Xor | 22:18 19 Dec '05 |
|
|
There is absolutely no reason to port Java syntax to C++. Adding expressions like synchronized() or using() you only mix the languages and complicate the code.
Java & C# lack of scoped object idiom that's why they need those expressions. C++ don’t!
{
Lock lock1(mutex1);
}
It’s better, more expected, and more understandable that
synchronized(mutex1)
{ }
|
|
|
|
|
| Needs Improvement
David Patrick | 1:02 19 Dec '05 |
|
|
1. The "Mutex" class should be "CriticalSection".
Since there is actually a Mutex in win32 and it is signficantly different from the Critical Section class in terms of implementation, functionality and performance characteristics it is very misleading to call the class Mutex when in fact it does NOT use a Mutex. It's a minor issue, but none-the-less may cause confusion for future maintance programmers.
2. Shouldnt the Lock::setUnlock() function actually unlock the mutex ?
Since all it does is set the boolean flag, in effect the scope of the synchronization lasts for the life of the Lock object created for the for loop .. the life span of this object is dependent upon compiler behavior and may extend beyond the scope of the specified synchronization block itself.
3. Speaking of the boolean flag ... was it really necessary ?
I like what you are trying to do, and I think you have a pretty good "first shot" ... I'm sure after a few revisions this will be a fine alternative to the current approach of just declaring the lock object inside the curly braces for the block which is to be synchronized ( I agree, the Java approach is more readable in some circumstances )
"We need less government, not more. The idea that we can become a better society by having a bigger rule book is ridiculous, regardless of who is trying to change the rules" - Doug Goulden
|
|
|
|
|
|
|
David Patrick wrote: The "Mutex" class should be "CriticalSection".
Well, it is just demo code. I prefer the short name Mutex instead of the long CriticalSection, also because a critical section is a mutual-exclusion object as well.
David Patrick wrote: Shouldnt the Lock::setUnlock() function actually unlock the mutex ?
Since all it does is set the boolean flag,
No, the function 'setUnlock' should not unlock the mutex. If it did, then it would be named 'unlock'. By using 'set' as a prefix, it is made clear that it has a different function. It could be named 'setUnlockFlag', if you like.
David Patrick wrote: the scope of the synchronization lasts for the life of the Lock object created for the for loop
Indeed, and that's the correct design: RAII dictates a resource be released upon destruction of the Lock object.
David Patrick wrote: the life span of this object is dependent upon compiler behavior
Microsoft compilers up to VC6 may have a problem. But as I am replying in the other post, that's Microsoft's problem, and not mine: they did not implement the VC++ 98 standard correctly. GCC has no problem.
David Patrick wrote: I like what you are trying to do, and I think you have a pretty good "first shot"
Well, feel free to modify it as needed. It was just a short sample anyway.
|
|
|
|
|
|
|
David Patrick wrote: the life span of this object is dependent upon compiler behavior and may extend beyond the scope of the specified synchronization block itself.
Using the workaround for Microsoft compilers described here[^] the macro would look like:
#if defined (_MSC_VER)
#define synchronized(M) if(0);else for(Lock M##_lock = M; M##_lock;M##_lock.setUnlock())
#endif
I'm not sure that it works without unpleasant surprise. 
Also, class Lock absolutely needs to make the copy constructor and operator= private.
|
|
|
|
|
| C++ versions ?
Robert Bielik | 23:57 18 Dec '05 |
|
|
As I recall, in VC++ 6 for statements like:
for (int i = 0; i < N; ++i)
{
// Do stuff
}
for (int i = 0; i < N; ++i)
{
// Do some other stuff
}
didn't work because i would be redeclared in the second statement. Does this imply that the mutex lock variable is not released upon leaving the "synchronized" scope?
If so, this would only work in C++ .NET 2002 and higher where this flaw is remedied.
|
|
|
|
|
|
|
Indeed, but that's VC6's problem and not mine. The C++ 98 standard says that the variables declared in a for statement are local to the for loop. It works fine for GCC.
|
|
|
|
|
|
|
That's a Microsoft extension. If you turn MS extensions off the issue goes away.
PeterRitchie.com
|
|
|
|
|
|
|
Ah, cool. Didn't know that. Thanx!
|
|
|
|
|
|
|
You could also put this in global include file:
#define for if(0){}else for
Cheers,
Pedro Alves
|
|
|
|
|
|
|
Or:
#define synchronized(M) if(0){}else for(Lock M##_lock = M; M##_lock; M##_lock.setUnlock())
...since this article was posted into the MFC section; it should work with Visual Studio, out of the box.
PeterRitchie.com
|
|
|
|
|
|
|
Last Updated 18 Dec 2005 |
Advertise |
Privacy |
Terms of Use |
Copyright ©
CodeProject, 1999-2010
