• 0

Windows' faulty multithreading system?


Question

Not sure if this thread belongs here, but anyways.

This guy, who was my Java tutor, claimed that the way Windows manages processes is sub par relative to Linux's multithreading.I didn't ask him for more explanation and as such he didn't go into details, but claimed that the processes in Windows are in fact threads that belong to one mother process and that is why-to his belief- Windows programs are subject to crashes that may bring the whole OS down.He said in Linux it is real multithreading and processing.

He reminded me of those Windows Media Player hangs when a crappy CD is inserted into the drive that often lead to most of the OS functions turning 'unresponsive'.Or IE lockups for that matter.

Funny thing though, is that I tried to reproduce the same problem in Kubuntu with Amarok 2 and it was even worse in another respect: When the cd was ejected, Amarok remained unresponsive forever so I had to close it manually.

That's in contrast with WMP where it resumes functioning as soon as the malformed CD is out the drive.

Also Vista doesn't seem to suffer from such issues.

Although, in a try to prove his point, he told me and my classmates to run this java code in both OS'es."This code should expose the faulty multithreading system of Windows."That's what the tutor claimed.

Here's the code:

//The Main class that execute the thread objects.
public class Main{
	public static void main(String args[]){
		Thread Tping=new Thread(new Ping());
		Thread Tpong=new Thread(new Pong());
		Tping.start();
		Tpong.start();
		try{
		Tping.sleep(1000);
		Tpong.sleep(1000);
		}catch(InterruptedException e){
		System.out.println("Exception occurred!");
		}
	}
}

//The Ping class, one of the threads.
public class Ping implements Runnable{
	public void run(){
		while(true){
			System.out.print("Ping");
		}
	}
}

//The other thread, Pong.
public class Pong implements Runnable{
	public void run(){
		while(true){
			System.out.print("Pong");
		}
	}
}

Try running this program in both Linux and Windows.I did it a while back, and I think the fault that the guy was suggesting came up when I moved the console winow or clicked in it ;The constant flux of "ping pong" was interrupted, that is the 'ping' suddenly shown up in the flow of 'pong' or vice versa.

In Linux, I didn't notice such phenomena, but I can't be sure.

So try it for yourself and see what comes out.

In any case, does it prove his point of a faulty multithreading in Windows?

edit- corrected the code mistake.

Edited by Aquarian
Link to comment
Share on other sites

Recommended Posts

  • 0

Sounds like he's talking about Windows 9x, the NT kernel is much more robust than the 9x one (A single app can't bring down the system)

Link to comment
Share on other sites

  • 0

He woudl have been right sometime around 1995, unfortunately that was some 14 years ago... and even then he was only half right.

But back then a lot of things ran under explorer. Today explorer doesn't "own" other apps in the same way. it was actually caused by the old graphics system though. and wasn't really th4e computer that hang, but rather the graphics that hung because one of the processes under it did so all it's resources went to that and it couldn't draw anything else. This hasn't been an issue in a decade almost.

and I think at the time Linux was much the same. but even so the linux graphics system at the time was so slow and crap you didn't really want to use it anyway :p

Link to comment
Share on other sites

  • 0

I don't take stance on the other things but you can tune the Linux kernel to have better multitasking (low latency) abilities than your average Windows set up (by using pre-emptive, realtime, low-hz kernel that's compiled with optimisations for your CPU architecture) so in that sense it's *possible* to make a Linux system that is more responsive under heavy load and multithreaded applications.

So with customisation, it can be done - most of the default kernels that ship with distributions do not do this however.

Link to comment
Share on other sites

  • 0

Is he older? I think his knowledge might be a bit outdated and based on experiences from Windows 9x. Back then, a single process could bring down the whole OS by overwriting an important part of the kernel (there was no real memory protection). That is not possible in NT, although a faulty driver can accomplish the same thing (any program communicates with a whole bunch of drivers).

He also doesn't seem capable of telling an application apart from the operating system. Windows Media Player is an application, as is Windows Explorer (although one could argue that WE is a core part of the OS, but it's still an application).

When WMP hangs, it's because it hasn't been programmed to account for certain error scenarios. If WMP is attempting to access the drive on the same thread that is responsible for the rest of the program and the call is synchronous and blocks, the whole program (or parts of it) will freeze because it's just sitting there waiting for an event.

The same thing did occasionally happen in Windows Explorer in XP and earlier, which is less forgivable since WE is an important application that you don't want to become non-responsive. The rest of the OS is still running when this happens though, including other processes, so his claim isn't really true (except maybe unless what was blocking was a faulty driver that was used by many parts of the system).

None of these are really Windows issues, they're basic problems that you (the developer) have to deal with on all platforms.

As for the Java code, I don't really know Java, but I'm not sure if I get what the program is supposed to do. It spawns two threads that each continuously print out the words "Ping" and "Pong" to the console? Well, what is that supposed to prove? Windows (and most OSes) makes no guarantee about which order the threads will be executed in or that they'll get an equal share of time (they might even both be running at the same time!). It's not simple round-robin scheduling. You're in a world of trouble if you write your programs with assumptions like that. It gets worse if you consider that moving a console window around might require that the console itself perform certain actions that take time.

Link to comment
Share on other sites

  • 0
...

But back then a lot of things ran under explorer. Today explorer doesn't "own" other apps in the same way. it was actually caused by the old graphics system though. and wasn't really th4e computer that hang, but rather the graphics that hung because one of the processes under it did so all it's resources went to that and it couldn't draw anything else. This hasn't been an issue in a decade almost.

...

You can still do that (GDI is still the main graphics subsystem), but it's a lot harder to do that now (on a 2MB graphics card, easy. On a 512MB card? much harder)

It wasn't just GDI causing issues though, it went right through the system to the very core (hence why MS converted the desktop line over to the NT kernel with XP)

Link to comment
Share on other sites

  • 0

Thanks for the explanations, guys.

@Eevo- Okay. :rolleyes:

@The_Decryptor- erm no.The 9x era might have skewed his view of Windows, though I'm pretty sure he was talkin about XP.Though I kinda lost faith in his words when he spewednonsense about the 'whole OS going down' thing.

@HawkMan- A decade? agoI dunno man, but I've had experiences with XP when Explorer stopped responding and the OS got a bit sluggish as well.Yet it could simply recover itself and most of the time didn't lead to an all-over crash, unlike what the tutor claims.

@daPhoenix- Such cases are sparse, I suppose.The default kernel for both both Windows and Linux suffice for the most part.

@hdood- Nice post.

The tutor is older than me yeah, he's not senile at all lol.He's at his 30, I guess.Pretty young.

The moment he opened his mouth with regard to the hangs and crashes, I figured he was just trying to bash Windows.

I think though he knows the difference between an applicationa and an OS.After all he's a veteran Java programmer.When the guy talked about crashes, he was not only pointing at Explorer, rather a complete freeze when you can't click the Start Menu.I've noticed such cases in XP to be honest.Nonetheless, I'm not sure if there's a correlation between such freezes and what he claims about Windows processes being actually threads.

That's why he came up with that code to prove his point.

According to him, when you move the console/terminal windows around and play with it somehow, it shouldn't interfere with the running threads in the program; it should be a steady flow of 'Ping Pong', a few constant lines of "Ping" followed in turn by a few lines of constant "Pong" and this process goes on and on until you stop the program by ctrl+c.

If by playing around with the Terminal/Console,clicking in it etc the normal flow is interrupted e.g a "ping" in the middle of the "pong" thread, then there must be somthing wrong with the multitasking subsystem of the OS under which the program is run.

So the program isn't about about the order by which the threads schedule and start.That's true, one can't expect that with a program like this, it's controlled by the OS itself.

I can't remember exactly if the problem ran good under Linux or not, but I guess it was running the way it was supposed to, no interruption in threads.I've thrown Linux away, so I can't test it again right now.

In XP though, I'm pretty sure it was not working correctly.Haven't tried on Vista.

Regardless of the guy's opinion about MS and Linux, whether he's a MS hater(actually he is) and whether his argument about Windows crashes holds water or otherwise, I think if the output of his little program shows different results under Linux and Win, it is safe to say that something is wrong with either OS.Don't you think?

hdood, If you want to test it out, you'll need three class files for the program to execute; One is Main.java, second Ping.java and third Pong.java

You'll compile Main.java by typing "javac Main.java" at the console and then run it by typing "java Main".Make sure you have JDK and that the correct environment variables are aet.

Thanks to anybody who test this program under both OS'es.

I don't want the tutor to make it in badmouthing Windows.

Link to comment
Share on other sites

  • 0

He probably was referring to XP, but he was probably referring to the wrong version anyway. He's a human (hopefully, no robot rebellion yet), and humans make mistakes (I had one IT teacher tell me ActiveX was MS's 3D game programming API and DirectX was their object linking and embedding API)

Windows may (does) handle threads differently than Linux does, but neither implementation is more "correct", you may get fairly consistent behaviour under one setup, but you'll get different behaviour under another (on a single core/uniprocessor system it's going to run one thread after another, on a multi-core/multi-processor system it'll run them at the same time)

Link to comment
Share on other sites

  • 0
Not sure if this thread belongs here, but anyways.

This guy, who was my Java tutor, claimed that the way Windows manages processes is sub par relative to Linux's multithreading.I didn't ask him for more explanation and as such he didn't go into details, but claimed that the processes in Windows are in fact threads that belong to one mother process and that is why-to his belief- Windows programs are subject to crashes that may bring the whole OS down.He said in Linux it is real multithreading and processing.

He reminded me of those Windows Media Player hangs when a crappy CD is inserted into the drive that often lead to most of the OS functions turning 'unresponsive'.Or IE lockups for that matter.

Funny thing though, is that I tried to reproduce the same problem in Kubuntu with Amarok 2 and it was even worse in another respect: When the cd was ejected, Amarok remained unresponsive forever so I had to close it manually.

That's in contrast with WMP where it resumes functioning as soon as the malformed CD is out the drive.

Also Vista doesn't seem to suffer from such issues.

Although, in a try to prove his point, he told me and my classmates to run this java code in both OS'es."This code should expose the faulty multithreading system of Windows."That's what the tutor claimed.

Here's the code:

//The Main class that execute the thread objects.
public class Main{
	public static void main(String args[]){
		Thread Tping=new Thread(new Ping());
		Thread Tpong=new Thread(new Pong());
		Tping.start();
		Tpong.start();
		try{
		Tping.sleep(1000);
		Tpong.sleep(1000);
		}catch(InterruptedException e){
		System.out.println("Exception occurred!");
		}
	}
}

//The Ping class, one of the threads.
public class Ping implements Runnable{
	public void run(){
		while(true){
			System.out.print("Ping");
		}
	}
}

//The other thread, Pong.
public class Pong implements Runnable{
	public void run(){
		while(true){
			System.out.print("Pong");
		}
	}
}

Try running this program in both Linux and Windows.I did it a while back, and I think the fault that the guy was suggesting came up when I moved the console winow or clicked in it ;The constant flux of "ping pong" was interrupted, that is the 'ping' suddenly shown up in the flow of 'pong' or vice versa.

In Linux, I didn't notice such phenomena, but I can't be sure.

So try it for yourself and see what comes out.

In any case, does it prove his point of a faulty multithreading in Windows?

edit- corrected the code mistake.

That could just be to do with the way that the Java VM on each machine is designed, it isn't necessarily a flaw with Windows. Windows has to attribute each thread to a process, so that it can terminate all the threads when the process terminates, but that is not a design flaw, it ensures stable system behaviour, and correct resource usage. However the threads are still executed seperately, so in reality he is wrong.

Link to comment
Share on other sites

  • 0
programmer.When the guy talked about crashes, he was not only pointing at Explorer, rather a complete freeze when you can't click the Start Menu.

Ah, but see, the Start Menu belongs to Windows Explorer, as does the desktop. Presumably you'd still be able to alt-tab to the various running programs.

If by playing around with the Terminal/Console,clicking in it etc the normal flow is interrupted e.g a "ping" in the middle of the "pong" thread, then there must be somthing wrong with the multitasking subsystem of the OS under which the program is run.

So the program isn't about about the order by which the threads schedule and start.That's true, one can't expect that with a program like this, it's controlled by the OS itself.

Well, it is about that though. You have two threads writing to the same console. Any thread could be writing to it at any time, and you can even have both writing at the same time (say you have a multi-core/thread processor). There's nothing about "multithreading" that says there have to be a "steady flow" like what you're describing.

Another problem with the test is that it doesn't just involve the two threads, but also a third part -- the console. This itself is another program, and how it deals with the stdin stream would be an implementation issue with the console itself rather than the scheduler. Maybe some of the print calls from the threads end up randomly blocking the threads because the console is busy doing other things when you're dragging it around, and then when the OS switches to the other thread that gets to complete its call because the console now has time.

Or maybe moving the action of moving the window requires CPU cycles for the window manager, which then reduces the time slot each thread gets so that they now only have time to write less text?

I don't know, there's just so many potential factors here that the test seems pretty meaningless. You can't even really argue that the two programs running on Windows and Linux are actually the same, because the Java runtime is different on the two platforms. One could argue that this fact alone invalidates the whole test.

I can't remember exactly if the problem ran good under Linux or not, but I guess it was running the way it was supposed to, no interruption in threads.I've thrown Linux away, so I can't test it again right now.

In XP though, I'm pretty sure it was not working correctly.Haven't tried on Vista.

But this is a fallacy. Does the OS actually make any guarantees that it's "supposed to" work that way? Or is that just an assumption being made? It seems like it's the latter.

I think if the output of his little program shows different results under Linux and Win, it is safe to say that something is wrong with either OS.Don't you think?

I don't think so. It just shows that they're different. It could even be that manipulating windows and the console code itself uses more resources on Windows, but even then you've just shown that Windows is a heavier OS.

Let's say this was the case, wouldn't you then want the OS to devote more resources to an interactive action like moving a window around at the expensive of less important background tasks? Wouldn't that just show that the scheduler was good?

He probably was referring to XP, but he was probably referring to the wrong version anyway.

XP is full of these problems though. Screwy optical drives, spun down HDs, unresponsive network drives, they all make Explorer freeze. I've seen it a thousand times. This is an issue of Explorer being **** though, and not related to any scheduling issues.

Link to comment
Share on other sites

  • 0
I'm pretty sure he was talkin about XP.

In which case, he probably doesn't know what he's talking about.

If by playing around with the Terminal/Console,clicking in it etc the normal flow is interrupted e.g a "ping" in the middle of the "pong" thread, then there must be somthing wrong with the multitasking subsystem of the OS under which the program is run.

Then he really doesn't know what he's talking about. The only way to guarantee that kind of synchronicity with any concurrent system (not just Windows) is to explicitly enforce it through things like mutexes, semaphores, etc. Guaranteeing such synchronicity in general is not only non-trivial, but would also defeat the purpose of concurrency. Even if you factor out anything that the OS might do with redrawing the console, processing mouse input, etc., there is still no guarantee of synchronicity. For example, consider something as simple as memory access: one thread may try to access a piece of memory not in cache and use up extra clock cycles waiting for that, or it might even relinquish its quantum all together if the memory needs to be paged in. Assuming that there should be some sort of inherent synchronicity that you did not explicitly establish is a great way to create bugs on any platform.

Link to comment
Share on other sites

  • 0
This guy, who was my Java tutor, claimed that the way Windows manages processes is sub par relative to Linux's multithreading.I didn't ask him for more explanation and as such he didn't go into details, but claimed that the processes in Windows are in fact threads that belong to one mother process and that is why-to his belief- Windows programs are subject to crashes that may bring the whole OS down.He said in Linux it is real multithreading and processing.
Processes in Windows have :
  • A private virtual address space
  • An executable program that is mapped into the process' virtual address space
  • A list of open handles to system resources that are accessible to all threads in the process
  • An access token (a security context that identifies the user, security groups, and privileges associated with the process)
  • A process ID (unique identifier)

while Windows threads have :

  • The contents of a set of CPU registers representing the state of the processor.
  • Two stacks, one for executing in kernel mode and one for executing in user mode
  • A private storage area called thread-localed storage for use by subsystems, run-time libraries and DLLs.
  • A unique identifier called a thread ID.

source

Not only that, but processes are very expensive to create, threads are much more lightweight. Processes are not threads, even under Windows. Saying they are "implemented using threads" doesn't mean anything. Processes under Windows have all the characteristics that define a process, therefore, they are processes. Linux is no different in that regard, threads and processes in Linux are basically the same thing.

Since the NT kernel, Windows is not inherently more subject to crashing than Linux; everything runs in user space except drivers, exactly like on Linux. Faulty drivers can crash the system on both OS; applications by themselves cannot. Applications can crash, of course, due to their own errors, but they cannot take down the system. In any case, that has nothing to do with the multithreading model, but to the user/kernel space differentiation.

Try running this program in both Linux and Windows.I did it a while back, and I think the fault that the guy was suggesting came up when I moved the console winow or clicked in it ;The constant flux of "ping pong" was interrupted, that is the 'ping' suddenly shown up in the flow of 'pong' or vice versa.

In Linux, I didn't notice such phenomena, but I can't be sure.

There's no guarantee that the outputs will not interleave; there's no guarantee on the order of the outputs either. You have two threads sharing the standard output, you cannot make any assumptions about the order in which their output will be displayed. This is true on both Linux and Windows. The program doesn't demonstrate anything, the output will be different depending on the system, the OS, the JVM implementation, how busy the system is, the zodiac, etc. Besides, it is incorrect as you present it here. The method sleep() is static and should be called statically by each thread :

public class Main {
	public static void main(String args[]) {
		Thread Tping = new Thread(new Ping());
		Thread Tpong = new Thread(new Pong());
		Tping.start();
		Tpong.start();
	}
}
//The Ping class, one of the threads.
public class Ping implements Runnable {
	public void run() {
		while (true) {
			System.out.print("Ping");
			try {
				Thread.sleep(1000);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
		}
	}
}
//The other thread, Pong.
public class Pong implements Runnable {
	public void run() {
		while (true) {
			System.out.print("Pong");
			try {
				Thread.sleep(1000);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
		}
	}
}

Edited by Dr_Asik
Link to comment
Share on other sites

  • 0

Thread and process scheduling is not deterministic to the application. The scheduler can decide whenever the **** it wants to run a thread, based on priorities and crap like that. Heavy system level activity can throw everything off, since kernel threads have higher priority. Multiple processors increase the fun, since both threads can actually truely run in parallel.

Link to comment
Share on other sites

  • 0
Not only that, but processes are very expensive to create, threads are much more lightweight. Processes are not threads, even under Windows. Saying they are "implemented using threads" doesn't mean anything. Processes under Windows have all the characteristics that define a process, therefore, they are processes. Linux is no different in that regard, threads and processes in Linux are basically the same thing.

I think what he meant by that is that the Process contains 1 or more threads, the thread being the basic execution structure.

Link to comment
Share on other sites

  • 0
I think what he meant by that is that the Process contains 1 or more threads, the thread being the basic execution structure.
Yeah probably. But does that mean the scheduling is any different from that of Linux? I'd need a solid source on that. In any case that has nothing to do with one application being able to take down the OS.
Link to comment
Share on other sites

  • 0

^ Lol, no doesn't explicitly mean it works any different. Not sure if POSIX threads work any differently to standard windows threads?

The only thing which screams at me when he says is is having trouble when moving the console window round, is that while he keeps moving it, the application thread (the one running the actual console) is being bombarded with window messages, and the other two threads are waiting to write out to the console. Not to mention you've got a java threading model running (on the runtime) on top of the OS threading API.

Link to comment
Share on other sites

  • 0
Not to mention you've got a java threading model running (on the runtime) on top of the OS threading API.

This is what I was thinking as well. There are most likely differences between the JVM implementations on top of any differences between the OS' threading model.

Try a C++ program if you want a fair comparison.

Link to comment
Share on other sites

  • 0

Alright.I admit I'm kinda overwhelmed by the level of technical stuff posted in this thread.You guys rock!

I don't know much about how threading system works and was just trying to paraphrase what the tutor said on this.Along the way, I might have succeded in getting his point across.Thus, I'll try to make time to visit him on wednesday.I'll bring this thread in front of his eyes and given his not-so-good English, I'll try my best to translate the important messages you posted for him accurately.I guess he will be lost for words with all this stuff you posted. :D Though, knowing him I'd say he will come up with a bunch of clearer answers,particularly since I think I couldn't get his point across exactly hereby.

So until then, I'll leave this thread to you guys.

I myself agree with most -if not all- of the points y'all made, especially the JVM one.

By the way, I tried to run the program in XP and didn't touch a thing in the meantime, just let the program go on for a few seconds.Guess what? The issue still happens even if I do nothing at all.Not that this proves anything, just wanted to clear up things.

threads.th.jpg

Thank you all very much for the great posts.Be sure to check back when I post his answers back...well, if he's got any.He's an open-minded guy though...

Link to comment
Share on other sites

  • 0
By the way, I tried to run the program in XP and didn't touch a thing in the meantime, just let the program go on for a few seconds.Guess what? The issue still happens even if I do nothing at all.Not that this proves anything, just wanted to clear up things.

threads.th.jpg

There's no "issue". It's perfectly normal to get several "Pongs" or several "Pings" in a row. Switching between threads is relatively costly for the OS, so it tries to let a thread run for a while before switching. In order to get a perfectly alternating PingPongPingPong, the OS would have to spend most of its time just switching between these two threads, which isn't very efficient.

In any case, the key point here is that you cannot make any assumption about how and when the OS will schedule your threads, in what order will they run, for how much time, etc. It is not an issue with the OS if you don't get the output you wanted, it's an issue with your program.

I don't think the JVM really changes anything to the equation as it's supposed to use native threads. A long time ago it used "green threads", that is, every Java thread ran in a single native thread and the JVM did the management, but that was slow and replaced with native threads.

Link to comment
Share on other sites

  • 0

Alright.

So I visited this guy yesterday and brought this topc up with him.

Mostly thanks to Dr_Asik posts, he did concur that threads and processes in Windows are no different than that of the Linux in that they are distinct from each other; thread is thread and process is process.Though their impmlementations has to be different on different OS'es by nature.

He also agreed to the fact that NT kernel is more robust and much less subject to crashes that could bring the whole system down(implying he was actually talking about Win 9x era at first).He was wrongly under the impression that when an application crashes in Windows, its executing thread would hog system resources and doesn't let the mother process to manage other threads, and that was assuming processes are in fact threads in Windows.But after realizing the truth and when I translated to him that the type of crashes depend on the privileges associated with the culprint program user/kernel space, he remained silent and pondering.

He's a Linux guy after all and that's why he doesn't know much as to how Windows works.He only touches Windows when it's inevitable, since Windows is 98% pirated here.You know ethics and all that.

He does certainly know his stuff when it comes to Java programming though.He's designed and programmed a number of enterprise apps with Java and even .Net, once his framework of choice.His latest effort was an open-source web-based code generator.

In his eyes, many of the posts in this thread suggest that his point of that little Java program wasn't understood properly.He doesn't expect the output of the program to be an alternating sequence of PingPongPingPong; he agreed that isn't quite possible with this kind of program.Rather, the output should look something like this, in its 'expected' form:

PingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPing
PingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingP
ingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPi
ngPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPingPongPongPongPongPongPongPongPon
gPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPong
PongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongPongP
ongPongPongPongPongPongPongPongPon

I put up an image of what is considered to be 'unexpected' in my previous post here.

Nonetheless, he accepted that this sort of a program isn't convincing enough to prove his point, especially when it's about threads that is rather a complicated topic.

Therefore, he told me that he'll try his best to write a program that is convincing enough to prove him in this regard.

Though seeing as he is quite busy these days with programming and stuff, it may take a while for him to finish the program.That said, he seemed very interested in this subject and wanted to clear it up for himself why and how the threading systems of Linux and Windows' are responding differently to this program and that which one actually handles it better.So I'm pretty sure he will come up with the next program sooner than later.

By the way, he told me to appreciate you guys on his behalf for all the informative posts which he certainly learnt from quite a bit. :)

when the OS will schedule your threads, in what order will they run, for how much time

The tutor didn't quite get your definition of time in that line.Can't we determine when a thread stops or till when it keeps running? Please elaborate, thanks.

oh and he confirmed your point on the JVM.

Link to comment
Share on other sites

  • 0

Wow, so many misconceptions in this thread, I don't know where to begin!

First off, let's talk about Windows NT and its descendants (XP, Vista, etc).

Windows NT was designed from the ground up for multi-threaded environments. It provides by far the most advanced threading architecture of any modern desktop OS. Each process can spawn as many threads as it wants, and each process runs in its own virtual memory space. An application absolutely cannot overwrite or otherwise impact the virtual memory of another process.

Now, what your teacher may have been referring to is the 16-bit virtual machine that Windows NT OSes provide for running MS-DOS and Win16 programs. When you run Win16 programs on an earlier NT OS, they run in a shared virtual machine that emulates a 486 with MS-DOS. If one of those programs crashes it can take down the VM and any other Win16 programs running in it. Even NT4 allowed you an option to run each Win16 app in a separate VM, and I'm 99% positive that is now the default behavior. However, the 64-bit versions of NT don't even include the Win16 VM... and really, nobody runs 16-bit apps any more.

Linux was originally designed as a single-threaded OS. Threads were tacked on later, but the early implementations were extremely poor, and threading before Linux kernel 2.6 was largely considered a joke. Nowadays it's reasonable, but surely nothing to write home about.

OS X had similar problems, though with a different cause. While its Mach microkernel is multi-threaded friendly, earlier versions had a very difficult time rationalizing the threading of the Mach kernel with the threading of the FreeBSD kernel that sits on top of it. They had a very messy and poorly scaling system called a "split funnel" that basically resulted in many of the most important operations being completely synchronized on a single lock. In Tiger they improved things a bunch, and they've continued to do so with Leopard. It appears that Snow Leopard will finally reach multi-threaded capaibilities rivaling Windows 2000 (with Grand Central offering functionality comparable to the NT thread pool and such).

The NT threading model has evolved over time, too. In Windows 7 some key bottlenecks that affected 32-core and greater machines (like the dispatcher spinlock) were removed, resulting in excellent scaleability up to at least 256 processors.

As for the earlier MS-DOS, Windows 3.x, and Windows 9x line...

MS-DOS supported protected memory, I believe beginning in DOS 3.5 but maybe it was as late as 5.0. Windows 3.x and 9x ran in protected mode, so one process could not stomp on the memory of another. This was the primary reason that Windows machines were so much more reliable when multi-tasking than their Mac OS counterparts, which didn't receive true protected memory support until OS X. Whereas Windows machines would just have one application terminate (remember, the Win9x BSOD wasn't fatal when it occured for an application in user mode, you just got abort / retry / fail kind of options), the Mac OS wouldn't even realize anything had gone wrong, and would happily overwrite memory, resulting in bizarre behavior usually quickly leading to a completely frozen system.

There was a great rant about this from John Carmack back in '99. My favorite part:

The [Mac OS] low level operating systems SUCKS SO BAD it is hard to believe. The first order problem is lack of memory management / protection.

...

The lack of memory protection is the worst aspect of mac development. You can just merrily write all over other programs, the development environment, and the operating system from any application.

I remember that. From dos 3.3 in 1990.

Protected memory is separate from threading, though. Windows 95 supported multi-threading support via the Win32 API. Its implementation wasn't as robust or scaleable as NT, but it worked, and supported pre-emptive multitasking (another thing Mac OS lacked for a long, long time).

Edited by Brandon Live
Link to comment
Share on other sites

  • 0
Although, in a try to prove his point, he told me and my classmates to run this java code in both OS'es."This code should expose the faulty multithreading system of Windows."That's what the tutor claimed.

Here's the code:

//The Main class that execute the thread objects.
public class Main{
	public static void main(String args[]){
		Thread Tping=new Thread(new Ping());
		Thread Tpong=new Thread(new Pong());
		Tping.start();
		Tpong.start();
		try{
		Tping.sleep(1000);
		Tpong.sleep(1000);
		}catch(InterruptedException e){
		System.out.println("Exception occurred!");
		}
	}
}

//The Ping class, one of the threads.
public class Ping implements Runnable{
	public void run(){
		while(true){
			System.out.print("Ping");
		}
	}
}

//The other thread, Pong.
public class Pong implements Runnable{
	public void run(){
		while(true){
			System.out.print("Pong");
		}
	}
}

Try running this program in both Linux and Windows.I did it a while back, and I think the fault that the guy was suggesting came up when I moved the console winow or clicked in it ;The constant flux of "ping pong" was interrupted, that is the 'ping' suddenly shown up in the flow of 'pong' or vice versa.

In Linux, I didn't notice such phenomena, but I can't be sure.

So try it for yourself and see what comes out.

In any case, does it prove his point of a faulty multithreading in Windows?

No, in fact it does quite the opposite.

The entire point of spawning two threads is that they run independently. It is impossible to predict the order in which two different threads are going to execute. It's entirely up to the scheduler, which at its most basically level switches between all the threads on the system giving them each a small amount of CPU time, and then freezing it and switching to the next. When you have multiple CPUs, you'll have multiple threads running at exactly the same time. Even on a single core system, there will be times when one thread doesn't finish its task of printing its output in the alloted time (because some I/O happened, some higher priority process interrupted it or caused it to have a smaller time slice, or a bunch of other possible reasons), so execution moves to the next one, which does print its text, then execution switches back to the other thread and it finished the first word (but now they appear out of order). So the order in which these two threads execute their commands is entirely dependent on the state of the system before and during their execution.

That's why we have synchronization mechanisms like locks, critical sections, semaphores, etc. If you want those threads to alternate between writing ping and pong, you're going to need to synchronize them. Of course, that kind of defeats the purpose of having two separate threads.

If you always got the same output and both threads just alternated, it may even indicate you have a very poor thread scheduler.

Edited by Brandon Live
Link to comment
Share on other sites

  • 0
Windows 3.x and 9x ran in protected mode, so one process could not stomp on the memory of another.

But you could stomp on certain kernel memory and bring the whole OS down.

There was a great rant about this from John Carmack back in '99. My favorite part:

In fairness to Apple though, Mac OS did originate on 68000 hardware with no MMUs, just like Amiga OS. At least that would have been a valid reason in 1991.

Link to comment
Share on other sites

  • 0
The tutor didn't quite get your definition of time in that line.Can't we determine when a thread stops or till when it keeps running? Please elaborate, thanks.

oh and he confirmed your point on the JVM.

I mean that when the OS schedules a thread, it won't necessarily let it run to completion. Maybe that's impossible (the thread is an infinite loop, maybe it will block on some input, maybe it will deadlock), but in the general case, there are other threads on the system waiting to get CPU time that can't stay idle for too long. So what the OS does is schedule a thread for a while, then put it to sleep, wake up some other thread, let it run for a while, wake up some other thread, etc. There's a very sophisticated algorithm for determining which thread(s) to run and for how much time, but what the OS basically does is periodically cycle through all the threads, ensuring no one is starving, i.e. not ever getting any CPU time. If you have multiple CPU cores then the OS can schedule multiple threads at the same time, but there are still many more threads than CPUs.

This is why I don't see how could you assume that you will get a specific series of Pings and Pongs. The scheduler is a very smart algorithm and takes a lot of factors into consideration, you can't predict what it's going to do. All you know is that if the system isn't too busy, your threads should get about equal CPU time on average.

Edited by Dr_Asik
Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.