The Monitor pattern vs the Monitor programming construct
Though, the monitor programming construct is always there to support the monitor pattern, it is important to understand the programming construct separately from the pattern. This is necessary because the pattern can be used with all modern threading libraries even if the ’specific programming language’ being used does not have any specific keyword for that.
Monitor as a programming language construct :
Basically, when supported, ‘monitor’ as a programming language construct is there to hide mutual exclusion. So if a procedure is defined to be a monitor then by definition that piece of code is taken to be a critical region. A critical region is a piece of code which can only be executed by one thread at a time. In case of a monitor the programmer himself does not have to put the critical region inside lock-mutex and unlock-mutex, the programming language would take care of it.
[ But this is not there in C++:
For example java has 'synchronized' keyword for monitors, java virtual machine has corresponding monitorentry and monitorexit opcodes, and when java virtual machine encounters monitorentry it acquires a lock, and similarly it releases the lock when encounters monitorexit - the opcodes are not used for monitor procedures but ultimately jvm works with the same principle of locking and unlocking ]
On the other hand the monitor pattern is something like (mutex for critical section) + (wait) + (notify) - the language that has a monitor-like keyword would have all the facilities but the programming language construct is not necessary to implement the pattern.
In C++, with boost 1.34 – replacing the monitor keyword would be as simple as having a scoped mutex :
#include <boost/thread/mutex.hpp>
boost::mutex someMutex;
void someMethod()
{
boost::mutex::scoped_lock lock(someMutex);
// more code
}
2 Comments »
RSS feed for comments on this post.
| TrackBack URI
You can also bookmark
this on del.icio.us or check the cosmos
I must say that i am impressed at the level of detail provided above. Please continue writing such articles. Even though we have better faster SMP and Multi-threaded CPU cores, we dont have the coding skills to utilize the power of such hardware. we are just embarking on such grounds (atleast in cases of networking applications).
Comment by sachin — August 2, 2008 @ 8:36 pm
Thanks Sachin for your comments. Thats true - guys like Herb Sutter are working hard on this (how to optimize multi-core). These are like short notes - so that I can check them whenever I need to remember something.
Comment by admin — August 5, 2008 @ 4:30 am