[MUD-Dev] Re: [Java] multithreading: update and a question

[Vadim Tkachenko]

Chris Gray wrote:

[skipped]

> I'd guess that whether or not you want one OS thread per Java thread
> would end up depending on how many Java threads you use, and how often
> you create and destroy them.

[speaking about me]

I'm creating and destroying threads deliberately carelessly, on demand,
'cause remember that the preliminary optimization is a mother of all
evil. The Jukebox as it is today survived almost 2 years before I
started (because needed to) to optimize it.

> If you end up with only about a dozen or less,

Nah, the estimate is a count of hundreds - based on the test results, I
consider a 1000 threads a reasonable default for a number of threads -
that was Linux & Solaris on PII/350 with 128M RAM, which is I guess not
considered a server configuration novadays.

> than going with native threads each is easy, and will work
> fairly well. I think we've talked before about having a pool of
> threads that can be used for whatever is needed, without having to go
> to the considerable expense of creating and recycling them. If the
> Java app really does need dozens of threads active at the same time,
> its likely going to be a tad slow no matter how you do it.
> 
> If you take the Solaris solution, then in a sense you get the best
> of both worlds. With few Java threads, you get an OS thread for each
> one, and make good use of multiple CPUs. With many Java threads, you
> are limiting the use of OS threads, but still getting your Java app
> going. Sounds good to me.

See, there's a drawback - the architecture solutions for one/one,
many/one and many/many are different. Java becomes a curse
portability-wise, because it's SUPPOSED to behave in the same way, but
depending on the platform implementation different people working on
different platforms will lose their (voice fibers? what's the English
term? am I making myself clear here?) shouting and trying to convince
each other in what sucks and what rules.

The only portable solution I see so far is to have a java.lang.Thread
wrapper as a base of a thread entity, and make it just a thread for
many/many (also for many/one, because it doesn't matter in this case),
and something more sophisticated for one/one.

> What's the name of the new lighter-weight threads in the new Windows
> systems?

Fibers?

> Perhaps they might be appropriate for Java threads, although
> I vaguely recall that there is no pre-emptive switching among them.
> 
>  >Please consider this as a technical question, not the OS war.
> 
> Awwww!

Have some more explosive stuff at hand, like: local user context...

--
Still alive and smile stays on,
Vadim Tkachenko <vt at freehold.crocodile.org>
--
UNIX _is_ user friendly, he's just very picky about who his friends are