SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : All About Sun Microsystems -- Ignore unavailable to you. Want to Upgrade?


To: Byron Xiao who wrote (15647)4/22/1999 9:36:00 PM
From: Stormweaver  Read Replies (1) | Respond to of 64865
 
I'm not a fan of NT so I won't address your MSFT related questions. The bonus of buying into a PC architecture is the fact that you could run NT at some time along with a myriad of other operating systems.

Regarding UNIX workstations, give me some reasons why I would buy into a proprietary hardware with limited application and add-on hardware scope? For workstation functionality, a PC running NT gives me everything I need for an office environment. For high end graphics development I have a myriad of choices now of powerful cheap graphic cards that blow away Sun creator offerings.



To: Byron Xiao who wrote (15647)4/22/1999 10:19:00 PM
From: QwikSand  Read Replies (1) | Respond to of 64865
 
...Does NT support both user level threads and kernel threads? I know that Solaris supports both, and when you invoke Solaris thread library, and thread library calls gets translated into system calls and are handled inside the kernel and they have special hardware to handle context switch. I am not sure how NT implements it

Byron, I'm not sure about this because I read about it a long time ago. But from what I remember, the difference between NT and Solaris when it comes to threads is that the thread is the kernel scheduling entity in NT; that is, the kernel knows about all the threads in a user process and the kernel schedules them. I think that Solaris instead has this concept of "lightweight processes" that are scheduled by the kernel, but don't correspond one-to-one with user threads. The Solaris user-level thread library schedules threads by multiplexing them on these "lightweight processes", usually without entering the kernel.

It's another reason NT doesn't scale as well as Solaris. You can have millions of threads alive in a Solaris machine and the scheduling load on the kernel stays reasonable. Because: the kernel doesn't need to know about all the threads at the user level. But with NT, the more threads you have, the heavier the scheduling burden on the kernel, since it knows about all of them.

They way I heard it explained, it's like if in New York City everybody had to have their own car, that would be NT threads, and the more people you had, the more cars and the more gridlock. With Solaris threads, everybody takes a "taxi" (the lightweight process), so the gridlock goes up much more slowly with more people, since a taxi services many people and you add taxis instead of cars.

This doesn't mean that NT would lose if you ran a benchmark and just measured context switch time with a tiny number of threads. It might win. But wait till you try to run NT on 64 processors. Answer: you don't.

Maybe that doesn't make any sense but oh well. It's another reason why NT is a dog. I think M$ has all kinds of people like Tandem and Sequent etc. trying to fix this problem since of course they can't do it themselves. Who knows, they may succeed one day.

Regards,
--QwikSand