<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
I don't quite understand your question. I'll answer related things.<BR>
Do you know notice the slow down in cvsup/cvsupd? I do. But I'm curious if it is just me.<BR>Everything except OpenBSD uses pthreads in cm3. Which I believe are always kernel threads though don't know 100%. (FreeBSD? NetBSD?)<BR>
OpenBSD always uses user threads. Its pthreads are user threads and don't work well enough for us.<BR>
Always pthreads: Unless you do something "special" -- rebuild with cm3 -DUSER_THREADS or such -- I edit m3core/src/thread.quake, since I don't have support for passing extra parameters around from scripts, dumb, I know.<BR>
<BR>
<BR>
The code I showed is not what Modula-3 does.<BR>
We just call pthread_lock_mutex.<BR>
It is what pthread_lock_mutex should look like.<BR>
Or perhaps something even better, but it is a simple efficient start.<BR>
<BR>
<BR>
We don't inline the locking, which Tony is keen on doing.<BR>
I don't think we inline for user threads locking either though.<BR>
Inline is often very good, but I don't know if it would be significant here.<BR>
<BR>
<BR>
Some profiling is probably in order.<BR>
<BR>
<BR>
You? had said that pthread_self or pthread_getspecific/set were showing in profiling?<BR>Some kernel calls where?<BR>
I don't believe any of those three are kernel calls, nor as well that pthread_lock_mutex is without contention.<BR>
We call self/getspecific/setspecific too often. But they should be fairly fast.<BR>
There is an approximate plan to improve this post-release -- use libunwind.<BR>
<BR>
<BR>
Again, maybe some profiling is in order.<BR>
Maybe just of hello world?<BR>
I'd have to test hello world user threads and kernel threads. See if it is noticably different.<BR>
Again, cvsup/cvsupd it is very noticable the speed of userthreads vs. kernelthreads. Heck, it maybe isn't even threads. Maybe it is just startup/shutdown.<BR>
<BR>
<BR> - Jay<BR>
<BR>
<BR>> From: dragisha@m3w.org<BR>> To: hosking@cs.purdue.edu<BR>> Date: Tue, 6 Apr 2010 08:14:40 +0200<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] lock performance, random thoughts (also current cvsup situation)<BR>> <BR>> It's good to read more about subject, which is what I usually do after<BR>> some tabula rasa thinking on it :).<BR>> <BR>> It looks like Linux has optimized this for some time now. Bias by way of<BR>> very fast operation in uncontended cases. <BR>> <BR>> What is current m3devel decision on this? And how I (with Linux and only<BR>> Linux) can feel this slowdown in cvsup at all? Is it because Elego<BR>> rebuild cvsupd and is not using Linux server-side??<BR>> <BR>> On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote:<BR>> > Yes, that's pretty much what modern Java implementations do.<BR>> <BR>> -- <BR>> Dragiša Durić <dragisha@m3w.org><BR>> <BR> </body>
</html>