[M3devel] swaping user threads for kernel threads w/o rebuilding everything?

[Daniel Alejandro Benavides D.]

Iconic Modula-3 threads would be user-level transparent threads of machine threads, but then you would need threading system to cope with.
I believe that current system is OK respect PTHREADS as much as is, this is specially true if there isn't one application that use threads of machine-level likely easier than other application users of them (see for example cvsup), cvsup has strong reliance on network idle times to decompress and use disk files to continue downloading over a two channel communication space, if you have server-side SMP-threads, then it's not easier to use them accordingly, because you still may have lower latencies queuing them and proportionately them to your users (your system will queue them as FIFO), but while your threads might finish connection faster, other user-level threads might need them more time to finish so they will be locked until (due network considerations and system dequeuing) clients get their messages off-time also, which is not fair if you are downloading small bits of code after other's longer chunks of code.
I learned this while downloading with user-level threads and faster than with network same conditions and same machine with p-threads'ed systems longer finish time. Now this is counter-wise effect, as I got this while downloading from user-level thread system.
Thanks in advance
Thanks in advance
http://modula3.elegosoft.com/cm3/

--- El sáb, 28/4/12, Jay K <jay.krell at cornell.edu> escribió:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] swaping user threads for kernel threads w/o rebuilding everything?
Para: "Mika Nystrom" <mika at async.caltech.edu>, dragisha at m3w.org
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: sábado, 28 de abril, 2012 18:59




To repeat myself: It'd be nice if both sets of code was compiled/linked together and the threading model was selectable via a command line switch and/or link-time option.
I understand that would inhibit inlining via function pointers/dynamic linking.
Inlining that we surely don't do anyway and whose analog doesn't occur in other C/C++ systems.
Taking/releasing a lock would always incur a function call through a pointer.


As it is, you can't even swap m3core.so out, because the types are too different. You have to recompile or at least relink everything.


I could do the work, but I believe so far that Tony doesn't want it.



 - Jay


> To: dragisha at m3w.org
> Date: Sat, 28 Apr 2012 09:50:38 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Mika's thread test, -tests read
> 
> 
> Yes I have done it with user threads on CM3.  
> 
> (BTW, that is the configuration I always use on Darwin and Linux for "work".)
> 
> There are a few ways of doing the configuration.  The main thing is that the
> file 
> 
> m3-libs/m3core/src/thread/m3makefile
> 
> contains the code >>>
> 
> include_dir ("Common")
> 
> 
> if equal (OS_TYPE, "WIN32") or equal(TARGET, "NT386")
>     include_dir ("WIN32")
> else
>     if (NO_USER_THREADS contains TARGET) or ((not defined("NOPTHREAD")) and USE_PTHREADS{TARGET})
>         include_dir("PTHREAD")
>     else
>         include_dir (OS_TYPE)
>     end
> end
> 
> <<<
> 
> NO_USER_THREADS and USE_PTHREADS come from the config file.
> 
>      Mika
> 
> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
> >Mika said it does not happen with user threads. But he also said he is =
> >using pm3 mostly=E2=80=A6 So question is - did he run it with cm3, any =
> >version, with user threads.
> >
> >What are build parameters for cm3 with user threads?=20
> >
> >On Apr 28, 2012, at 2:58 PM, Antony Hosking wrote:
> >
> >> That means it is even more serious.
> >> Can we verify that it only happens with pthread threading?
> >>=20
> >> Sent from my iPad
> >>=20
> >> On Apr 28, 2012, at 1:49 AM, Dragi=C5=A1a Duri=C4=87 =
> ><dragisha at m3w.org> wrote:
> >>=20
> >>> It's not only AMD64_* if it's any consolation: :)
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120429/45ebc364/attachment-0002.html>