On Jul 23, 2008, at 7:18 PM, David Holland wrote:

quoted text
> On Wed, Jul 23, 2008 at 03:52:09PM -0700, Jason Thorpe wrote:
>>> You can do a lot of synchronization, as long as it's synchronization
>>> with other threads in the same process. Nothing in principle says  
>>> you
>>> need to go into the kernel for every synchronization op; and in fact
>>> you shouldn't, unless you're synchronizing with another process or
>>> you've run out of runnable threads.
>>
>> And, on UP systems, you don't.
>
> Shouldn't on MP systems either :-)
>
> (not that I know if we do or not, I haven't looked inside libpthread
> in a couple years.)

That, I think, is implied -- an MP system needs to have the atomic  
operation primitives that locks are built upon, which is why I didn't  
mention it :-)  The whole argument for SA seems to be "faster on UP  
systems".

quoted text
>> I just don't believe that there are very many apps that actually  
>> behave
>> like this.
>
> 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.

Right, well, the idea all those years ago is that apps would create  
billions of threads.  But if course it didn't really turn out that  
way.  In my day job, I am responsible for an app that creates ~150  
threads or so and pretty much everyone involved with it (including me)  
thinks that's way too many.

quoted text
> Both of these things are likely to change over the next five to ten
> years. (Unless the industry decides instead to just stagnate, which is
> a distinct possibility.)

Eh, that's not really the feeling I have... Can you elaborate?

-- thorpej