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

[Tony Hosking]

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
>