Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ MT-multithreading and servers » sMutexLock implementation
sMutexLock implementation [message #15998] Thu, 22 May 2008 10:38 Go to next message
hojtsy is currently offline  hojtsy
Messages: 241
Registered: January 2006
Location: Budapest, Hungary
Experienced Member
In Mt.cpp there is
Mutex& sMutexLock()
{
	static Mutex *section;
	if(!section) {
		static byte b[sizeof(Mutex)];
		section = new(b) Mutex;
	}
	return *section;
}

How is this different from the simpler
Mutex& sMutexLock()
{
	static Mutex m;
	return m;
}

In both cases the Mutex constructor will be called when the function is first called. In both cases the function needs external protection from MT race conditions.

On a side note, this function is not on the interface (Mt.h), why not make it file static in Mt.cpp to avoid name clashes?
Re: sMutexLock implementation [message #16178 is a reply to message #15998] Fri, 30 May 2008 19:11 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
hojtsy wrote on Thu, 22 May 2008 04:38

In Mt.cpp there is
Mutex& sMutexLock()
{
	static Mutex *section;
	if(!section) {
		static byte b[sizeof(Mutex)];
		section = new(b) Mutex;
	}
	return *section;
}

How is this different from the simpler
Mutex& sMutexLock()
{
	static Mutex m;
	return m;
}

In both cases the Mutex constructor will be called when the function is first called. In both cases the function needs external protection from MT race conditions.

On a side note, this function is not on the interface (Mt.h), why not make it file static in Mt.cpp to avoid name clashes?


I think you are basically right. This was attempt to make more sure that initialization really happens and there is not catch, because external protection is not possible there.... as this is a mutex used to protect synchronization of other mutexes..

So the whole thing is meant to be run before second thread starts (and it is called in several places to ensure this).

I guess it is still better this way, as you never know what really happens in "static magic".

I agree about "static" though.

Mirek

Mirek
Previous Topic: WaitForMultipleObjects() analog?
Next Topic: About U++ plugin/port of Webkit
Goto Forum:
  


Current Time: Fri Apr 19 21:44:33 CEST 2024

Total time taken to generate the page: 0.06065 seconds