<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>I remember that someone inside Acorn reported their use was overwhelming if running in user mode and gave an interesting idea about that in terms of operating system development. They wrote a huge amount of Modula-2+ code even with GUI in Acorn (Olivetti) for the Acorn Archimedes workstation in middle end eighties for its development<br>As the language primitives were the same in use at DEC SRC I guess they didn't consider the language as the problem, but a machine architecture lack of performance factor and in turn affect programs performance by itself. However this got into the development of the ARM architecture introduced since then for the Archimedes ARM and the OS itself.<br>http://lists.cloud9.co.uk/pipermail/bbc-micro/2010-January/007795.html<br>http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252swp.txt<br><br>As a new
operating system belongs to a new era the SPIN OS was ahead of its time in terms of performance improvements and no been hit by itself (in terms of performance) which was not an issue because of its nature of safety but still they addressed the use of other operating system code at the operating system level which of course gave problems of performance but didn't play a important issue by itself as non safe code could be extra checked or run in space of kernel with no user rights to modify heap allocated space or if not needed to be run in kernel space as a client of an extern library OS in user space with no use in kernel space<br><br>IMO both approaches either hardware level and operating system level have pros and cons as the operating system level threading is a plus nowadays in multi threaded programs running on multi core equipped hardware but in most cases the use of it could be not a winning situation because not all hardware by its
own is multi core in new computer Minis (net books) or systems run in hardware assisted virtualization and not to forget old machines which in most cases can run many applications no multi threaded of today like we use in normal with no performance improvement in new ones on tasks which may no benefit of the extra hardware that may still have at hand so there could be a balance that could benefit most of all cases. Therefore not to say that we may suck user level threading but still considering as a important part of it and needing a new development for the cases of lack of performance an improvement over the cases it lacks and better use of the better hardware like in Acorn did use of the new development to aid it.<br><br>Probably the best solution is a matter of match between the underlying hardware with proper system-level handling of it to best performance and less penalty in favour of the language developer and final user just to get easier of
development and performance gain solution.<br> <br>My vote for operating system level threading (i.e of SPIN) if lacks of performance of faster user threading as a solution for the performance hit problems and user level threading for the systems with no gain over it so we may gain of language and hardware capabilities to extract the best of both. <br><br><br>--- El <b>lun, 5/4/10, Jay K <i><jay.krell@cornell.edu></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Jay K <jay.krell@cornell.edu><br>Asunto: Re: [M3devel] lock performance, random thoughts<br>Para: dragisha@m3w.org, "Tony" <hosking@cs.purdue.edu><br>CC: "m3devel" <m3devel@elegosoft.com><br>Fecha: lunes, 5 de abril, 2010 19:13<br><br><div id="yiv1151963587">
<style><!--
#yiv1151963587 .hmmessage P
{
margin:0px;padding:0px;}
#yiv1151963587 .hmmessage
{
font-size:10pt;font-family:Verdana;}
--></style>
pthread_mutex_lock/unlock does not imply a kernel call. !<br>
pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design.<br>
Only upon contention is a kernel call needed, in both.<br>
<br>
<br>
That's not to say that everyone implements this well.<br>
Linux does.<br>
Win32 does.<br>
The others I don't know.<br>
<br>
<br>
Also Tony avoids even atomic operations often.<br>
I'm not sure how others compare there.<br>
I'm just referring to kernel/syscalls.<br>
Are they really so terrible?<br>
<br>
<br>
- Jay<br><br> <br>> From: dragisha@m3w.org<br>> To: hosking@cs.purdue.edu<br>> Date: Tue, 6 Apr 2010 01:57:07 +0200<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] lock performance, random thoughts<br>> <br>> I've used Java for one project, "GUI" app frontend for mobile phones...<br>> What I saw first was their mixup of mutex/condition/cheese in single<br>> root object... But, ok... offtopic there :)<br>> <br>> What I think is important about whole idea is it's simplicity and<br>> (almost) obvious efficiency. It also needs nothing fancy (not today, at<br>> least) and nothing maybe-it-works to implement. Nothing comparable to<br>> early implementations of kernel space threading/thread suspending for<br>> gc/...<br>> <br>> Any takers? :)<br>> <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>> -- <br>> Dragiša Durić <dragisha@m3w.org><br>> <br>
</div></blockquote></td></tr></table><br>