[M3devel] up-front initialization of mutex/conditionvariable?

[Jay K]

ps: maybe we can hope for the folks under us implementing pthread_mutex and criticalsection to do a very good job?

We have much more context??

Inlining??

 

 - Jay

 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Tue, 15 Dec 2009 04:04:17 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable?



Is it possible to do on Win32?
Win32 critical sections are cheap and already probably work roughly "that way".
Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap.
 
Our (new) win32 condition variables are not cheap, but similar in cost to Java.
(Java has one criticalsection per "monitor", merging the lock and the conditionvariable and sharing the criticalsection, where we have one per lock and one per conditionvariable.)
 
 - Jay

 
> Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable?
> From: hosking at cs.purdue.edu
> Date: Mon, 14 Dec 2009 22:49:48 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> We don't want to do that. We will avoid the lock in much more profitable ways. In fact, we want to go the opposite direction and inflate a fat pthread mutex/CV only if we really need to:
> 
> Bacon, D.F., Konuru, R.B., Murthy, C., Serrano, M.J.: Thin locks: Featherweight synchro- nization for Java. In: Conference on Programming Language Design and Implementation (PLDI). pp. 258–268. Montre ́al, Canada (Jun 1998)
> 
> Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot
> 
> Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 79–90. Monterey, California (Apr 2001), http://www.usenix.org/publications/library/proceedings/jvm01/dice.html
> 
> Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479–495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf
> 
> Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130–141. Seattle, Washington (Nov 2002)
> 
> Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223–237. Denver, Colorado (Nov 1999)
> 
> Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559–583. No. 3086 in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 2004)
> 
> Russell, K., Detlefs, D.: Eliminating synchronization-related atomic operations with biased locking and bulk rebiasing. In: Tarr, P.L., Cook, W.R. (eds.) Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 263–272. Portland, Oregon (Oct 2006)
> 
> On 14 Dec 2009, at 22:06, Jay K wrote:
> 
> > Is it possible to initialize mutexes and condition variables right away?
> > Instead of having the delayed initialization?
> > 
> > 
> > Mutex initialization is pretty fast on Windows, no syscall.
> > Having it be delayed like it is maybe isn't worthwhile.
> > 
> > 
> > As far as I know, the interface is just "NEW(MUTEX)" and the only that can run is, like, "constant field initializers", not calls to any code/"constructors". ?
> > 
> > 
> > I know there is the idiom NEW(T).init() but that is up to callers to adhere to.
> > Hm. I know Modula-3 was avoiding creating unnecessary language features, but in this case it seems maybe the wrong thing? Too late I guess.
> > 
> > 
> > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init?
> > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete.
> > 
> > 
> > - Jay
> > 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091215/d1a82760/attachment-0002.html>