I've been talking to Chris Gilbert for a while about eliminating nested interrupts in one or more of the ARM ports. Ignoring IPL_SOFT* IPLs for the moment, ARM currently has IPL_NONE < IPL_VM < IPL_SCHED < IPL_HIGH Since IPL_SCHED == IPL_CLOCK, once IPL_SCHED is reached you block clock interrupts. Since clock interrupts are the highest priority interrupts, you have basically blocked all interrupts. So there is little difference between IPL_HIGH and IPL_SCHED. So why have both? Ca...

I guess the first is because the compiler has detected that 'get_shared' doesn't set '*rci' in all paths. Similarly for '*variable' in lookup_mapper_entry. David -- David Laight: david@l8s.co.uk

As far as I can tell, this is the fictional application that M:N is targeted at: tens of thousands of threads running in userspace, doing nothing but synchronizing among themselves. In other words, an app that does nothing. 10 years ago that might have seemed new and cool, even necessary, but people have begun to get to grips with multithreaded programming and it's now obvious that thread synchronization is to be avoided at all costs. Even that fictional app will break down with more than one CPU,...

Shouldn't on MP systems either :-) (not that I know if we do or not, I haven't looked inside libpthread Right now there aren't, overall, very many apps that are threaded such that the threading buys much in the way of performance. There also aren't, overall, very many apps that make 10,000 user threads, because it doesn't work, at least not without using Erlang or some other similar environment with its own threading code. Both of these things are likely to change over the next five to ten y...

Different area, I know, but working in Erlang, creating 150 threads don't even raise an eyebrow. So, as usual, it all depends on where you work, and with what. As for the rest of the discussion, I'm staying out of it. I've just come to the realization that NetBSD don't fit my hand that well anymore. Johnny

Just because there aren't many apps that you know of doesn't mean there aren't any at all, nor that there is no potential for growth in this area. There are a lot of apps that use state threads, which is essentially a non-preemptive analog to scheduler activations. This is very useful for applications that have to handle a lot of small tasks that have to process work pipelines where each step in the pipeline involves a wait for some event to occur - either another thread to finish...

No argument here. However, in practice there's no decent scheme compiler to use for this, so people wind up doing it in C with threads or state threads. In my experience, the cases where you need threads and not continuations are rare, and a lot of extra work is needed when doing threads that's completely unnecessary. Nevertheless, people persist in programming in C because there are good compilers, and continuations are... hard... in C. Anyway, the more I think about this th...

It should only force kernel+libc+libpthread (and, really, libc +libpthread should probably be just in a single library). -- thorpej

Unification seconded. And while in there, there should be no difference between "single-threaded without pthread" and "single-threaded with pthread" like there currently is.

I keep hearing this and in my experience it's not true. One test case I can think of is MySQL and the supersmack benchmark. It makes heavy use of thread synchronization and issues lots of trival queries. Whatever gains SA makes in the thread synch area are blown away by the overhead it imposes on kernel If context switch is slow on ARM then why not make it faster? The entire system would benefit, not just threading. A lot of time was invested in the I don't have such a platform, but I can provid...

Not only context switch, but it also needs a new LWP (kernel thread) when blocking. In a case of new pthread (userland) or cold "LWP-cache" (actually, it is pool) it means: creation of new LWP + context switch. Also, at some point LWP should be destroyed or put back to the "LWP-cache", what means more overhead, or well.. wasting of memory. Imagine a case of 1000 (new) pthreads which block - that would mean: 1000 * (LWP creation + SA context switch) operations. Plus, LWPs for VPs... -- Best re...

Not exactly. To create LWP when blocking (that is, switching the context) SA invents a lot of complexity, and hacks (eg. locking against order). Also, But well.. what Andrew said - let's rather spend time optimising the context Bringing SA back invents more than 3000 lines of very complicated code. Why? - To support specific backwards compatibility which we never actually supported (see what Andrew and Jason wrote). - To support theoretical performance for some workload, where seems nobody...

Oops, forgot to attach the file.

>>>>> On Thu, 24 Jul 2008 09:25:09 -0700, Yes, of course, because it was measured 5 years ago. There wasn't netbsd-1:1 at that age. But I'm sure that netbsd-1:1 is slower than netbsd-SA, since all 1:1 implementations require kernel/userland context switch, while userland implementations and SA don't need it at all. There is no reason that netbsd-1:1 can be comparable with netbsd-SA in this particular benchmark. Probably netbsd-1:1 will be equal to redhat9-nptl at best, or perhap...

As far as I am aware, statically linked pthreads applications have never worked / been supported. We should drop any and all illusions of it working by NOT installing the .a file. I think the only platform we "support" that doesn't have dynamic linking is m68010 (sun2). -- thorpej