tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: revivesa status 2008/07/09

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

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".

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.

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

Home | Main Index | Thread Index | Old Index