<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Is it possible to do on Win32?<BR>
Win32 critical sections are cheap and already probably work roughly "that way".<BR>
Initialization is cheap. Cheaper than Java's locks. Uncontended locking is cheap.<BR>
<BR>
Our (new) win32 condition variables are not cheap, but similar in cost to Java.<BR>
(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.)<BR>
<BR>
- Jay<BR><BR> <BR>> Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable?<BR>> From: hosking@cs.purdue.edu<BR>> Date: Mon, 14 Dec 2009 22:49:48 -0500<BR>> CC: m3devel@elegosoft.com<BR>> To: jay.krell@cornell.edu<BR>> <BR>> 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:<BR>> <BR>> 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. 258268. Montre μal, Canada (Jun 1998)<BR>> <BR>> Dice, D.: Biased locking in HotSpot, http://blogs.sun.com/dave/entry/biased_locking_in_hotspot<BR>> <BR>> Dice, D.: Implementing fast Java monitors with relaxed-locks. In: Java Virtual Machine Research and Technology Symposium (JVM). pp. 7990. Monterey, California (Apr 2001), http://www.usenix.org/publications/library/proceedings/jvm01/dice.html<BR>> <BR>> Franke, H., Russell, R.: Fuss, futexes and furwocks: Fast userlevel locking in Linux. In: Ottawa Linux Symposium. pp. 479495. Ottawa, Canada (Jun 2002), http://www. kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf<BR>> <BR>> Kawachiya,K.,Koseki,A.,Onodera,T.:Lockreservation:Javalockscanmostlydowithout atomic operations. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 130141. Seattle, Washington (Nov 2002)<BR>> <BR>> Onodera, T., Kawachiya, K.: A study of locking objects with bimodal fields. In: Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). pp. 223237. Denver, Colorado (Nov 1999)<BR>> <BR>> Onodera,T.,Kawachiya,K.,Koseki,A.:LockreservationforJavareconsidered.In:Odersky, M. (ed.) European Conference on Object Oriented Programming (ECOOP). pp. 559583. No. 3086 in Lecture Notes in Computer Science, Springer, Oslo, Norway (Jun 2004)<BR>> <BR>> 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. 263272. Portland, Oregon (Oct 2006)<BR>> <BR>> On 14 Dec 2009, at 22:06, Jay K wrote:<BR>> <BR>> > Is it possible to initialize mutexes and condition variables right away?<BR>> > Instead of having the delayed initialization?<BR>> > <BR>> > <BR>> > Mutex initialization is pretty fast on Windows, no syscall.<BR>> > Having it be delayed like it is maybe isn't worthwhile.<BR>> > <BR>> > <BR>> > 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". ?<BR>> > <BR>> > <BR>> > I know there is the idiom NEW(T).init() but that is up to callers to adhere to.<BR>> > 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.<BR>> > <BR>> > <BR>> > In the pthread initialization, can we just copy from a statically initialized never used mutex? Or we must call pthread_mutex_init?<BR>> > I think we must call pthread_mutex_init, at least if we are to call pthread_mutex_delete.<BR>> > <BR>> > <BR>> > - Jay<BR>> > <BR>> <BR> </body>
</html>