<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
> That thread can then release and acquire as often as it likes, no further CAS, no <BR>
> pthread_mutex_lock. Acquirers must always CAS to see if the bit is set<BR>
<BR>
How does the thread know it doesn't need to CAS?<BR>With a non-atomic check?<BR><BR>
<BR> > polls a thread-local <BR>
<BR>
Expensive currently.<BR>
<BR>
Can be improved a la gcc __thread, Win32 __declspec(thread), but with limits.<BR>
<BR>
__declspec(thread) doesn't work pre-Vista with .dlls loaded "after" the .exe.<BR>
<BR>
<BR>
You can detect that though and switch between two paths.<BR>
The "reserved" parameter to DllMain tells you if you are loaded in CreateProcess or LoadLibrary, and therefore if __declspec(thread) works pre-Vista or if you need to use TlsAlloc/TlsGetValue.<BR>
<BR>
<BR>
You wouldn't want to inline that though, so "poll a thread local" is a function call.<BR>
If there are multiple backward branches in a function, you can optimize by remembering the address of the thread local in a "normal" local, certainly.<BR>
<BR>
<BR>
You can also possibly..I haven't thought this through, but I think for each function you can generate two entry points. Call them "internal" and "external". "internal" takes an extra pointer, the pointer to the thread locals. "external" gets the thread locals in an expensive fashion (above) and calls "internal". If a function doesn't actually need the thread locals, the two are aliased to each other.<BR>
<BR>
<BR>
Within a module (a single .m3 file), you always call internal, or maybe within a library/dll, or maybe within Modula-3 entirely. But callbacks or direct calls from C go to external. Though callbacks can do better. Even C calls could do better, if you can break the C/Modula-3 ABI.<BR>
<BR>
<BR>
I'm not sure this overall scheme works out, but I think it does.<BR>
<BR>
<BR>
This is similar to how in some systems exported functions are duplicated.<BR>
The exported version retrieves the base pointer for the .dll's data and then calls the non-exported one. NT/PPC, NT/IA64, I think Mac/CFM/PPC and others work this way. I believe it helps achieve position independence, all static data is accessed via a register that is maintained for all entry and/or exit from a .dll.<BR>
<BR>
> calls to <*EXTERNAL*> procedures <BR>
<BR>
Arguably we can do whatever needed in our .c code.<BR>
You know, since <*external*> is now largely but not completely implemented by us.<BR>
I realize there's still e.g. X/Windows, OpenGL, Win32. Only "libc" is wrapped aggressively right now, and others are large. And maybe that is all that should be, e.g. OpenGL and Xlib are very portable and so maybe cloning their headers is too?<BR>
<BR>
- Jay<BR> <BR>> From: hosking@cs.purdue.edu<BR>> Date: Mon, 14 Dec 2009 23:39:08 -0500<BR>> To: jay.krell@cornell.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] up-front initialization of mutex/conditionvariable?<BR>> <BR>> So, the basic scenario is as follows. Briefly... We should ditch signals as a mechanism for stopping threads. The compiler should inject a "safe-point" at each procedure call and backward branch. At safe-points, the thread polls a thread-local to see if the run-time system needs it to step out-of-line for some reason. At calls to <*EXTERNAL*> procedures we set a thread-local to say the thread is stepping outside Modula-3 code, with corresponding synchronized test on return in case the run-time needs it to pay attention. Now, when a MUTEX is first acquired, we simply CAS in a bit in the MUTEX along with the acquiring thread's ID. That thread can then release and acquire as often as it likes, no further CAS, no pthread_mutex_lock. Acquirers must always CAS to see if the bit is set. If it is then the lock is reserved for some other thread. We must revoke the reservation by handshake (as described above) with the reserving thread. We then inflate a real pthread_mutex_lock along with any queues needed for the MUTEX/CV. The handshake mechanism can also be used for stopping threads for GC, etc.<BR>> <BR>> The point is that uncontended locks should cost almost nothing.<BR>> <BR>> On 14 Dec 2009, at 23:04, Jay K wrote:<BR>> <BR>> > 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, Califor! nia (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 200 4)<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 call! ers 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>> <BR> </body>
</html>