[M3devel] lock performance, random thoughts (also current cvsup situation)

[Jay K]

I don't quite understand your question. I'll answer related things.

Do you know notice the slow down in cvsup/cvsupd? I do. But I'm curious if it is just me.
Everything except OpenBSD uses pthreads in cm3. Which I believe are always kernel threads though don't know 100%. (FreeBSD? NetBSD?)

  OpenBSD always uses user threads. Its pthreads are user threads and don't work well enough for us.

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.

 

 

The code I showed is not what Modula-3 does.

We just call pthread_lock_mutex.

It is what pthread_lock_mutex should look like.

 Or perhaps something even better, but it is a simple efficient start.

 

 

We don't inline the locking, which Tony is keen on doing.

I don't think we inline for user threads locking either though.

Inline is often very good, but I don't know if it would be significant here.

 

 

Some profiling is probably in order.

 

 

You? had said that pthread_self or pthread_getspecific/set were showing in profiling?
Some kernel calls where?

I don't believe any of those three are kernel calls, nor as well that pthread_lock_mutex is without contention.

We call self/getspecific/setspecific too often. But they should be fairly fast.

  There is an approximate plan to improve this post-release -- use libunwind.

 

 

Again, maybe some profiling is in order.

Maybe just of hello world?

  I'd have to test hello world user threads and kernel threads. See if it is noticably different.

  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.

 


 - Jay

 

 
> From: dragisha at m3w.org
> To: hosking at cs.purdue.edu
> Date: Tue, 6 Apr 2010 08:14:40 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] lock performance, random thoughts (also current cvsup situation)
> 
> It's good to read more about subject, which is what I usually do after
> some tabula rasa thinking on it :).
> 
> It looks like Linux has optimized this for some time now. Bias by way of
> very fast operation in uncontended cases. 
> 
> What is current m3devel decision on this? And how I (with Linux and only
> Linux) can feel this slowdown in cvsup at all? Is it because Elego
> rebuild cvsupd and is not using Linux server-side??
> 
> On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote:
> > Yes, that's pretty much what modern Java implementations do.
> 
> -- 
> Dragiša Durić <dragisha at m3w.org>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100406/5b387474/attachment-0002.html>