OSDev.org

I was wondering what people thought about the whole threading model of concurrent programming. From a few articles I have read, it seems like there are many arguments for using a threading model and many for using a more UNIX-y lightweight process model. What do people think is better, both for the operating system designer and for the application programmer?

In my semi-educated opinion, it seems like threads are an unnecessary complication on both levels. On the OS side, you need to coordinate a system of managing threads and their stacks as well as linking them to processes. It also seems to inherently mix in too much policy, like the decision on whether to kill a process when a thread faults or instead kill just that thread. On the application side, it seems like threading can give you a whole mess of bugs and pitfalls that can never happen in sequential code: synchronization, race conditions, deadlocks.

The only thing that seems to be against lightweight processes is performance. How big is this gap really? I have lightning fast IPC in my design, so maybe lightweight processes could even beat out user threads for me. From what I read in TAOUP (quite biased...) the whole threading concept stems from the relatively slow IPC and lack of (v)fork() call in MS-DOS/Windows. Is there truth to this?

Edit:
And what about an event driven design in place of threads? The core of my kernel is completely event driven, and my userspace supports preemptible event handlers. Is a set of closely communicating lightweight processes that use events a good model for replacing threads? So far, that's why my design entails.

For me, this is less of an OS level concern, because my kernel already provides primitives that, fit together properly, could create user threads. I also could care less about pthreads - POSIX is not my religion , although general UNIX philosophy is.

Funny, just a few seconds ago I was looking at this post.

What really is the difference between a thread and a lightweight process?

If you have several objects working on the same pool of data then you are more than likely going to need locking and mutual exclusion unless you can partition the data.

Even if your IPC is super fast then its going to be slower than two threads in the same address space working on the same memory.

Also what if you want a process to be able to continue working on data while reading data? Or have a process scale to the number of processors available? I think threads are here to stay.

On an implementation level they really aren't that hard to do. Yes you need to create some rules and stick to them but I think that under many circumstances they can be faster and under others lightweight threads might be a better pick so why not let the programmer pick which is best for his code?

Well, I would say the main difference is that lightweight processes have their own process entities, which means they are easier to manage in the kernel. They also encourage IPC over just writing to shared memory.

And I think that IPC can be almost as fast as just writing to memory. If my IPC gives only a 5% overhead to a task switch (which it probably does), since threads need to do task switches too, it is only 5% slower than two threads. But then you also don't have to use things like mutexes (mutexen?) and semaphores, which can have significant overhead.

Single processes shouldn't need to scale to multiple processes, at least in the process model. You have multiple instances of a process running on separate processors and communicating with IPC instead. This is what is used for scientific calculations and supercomputing because threads are slow and complex - there's no argument that it doesn't scale. If you modularize, you get concurrency easily.

And I'm not sure how I missed that thread, syntropy. It seems like they all agreed that events were better, and tried to figure out how to implement continuations well - there's some really interesting stuff there...

NickJohnson wrote:Well, I would say the main difference is that lightweight processes have their own process entities, which means they are easier to manage in the kernel. They also encourage IPC over just writing to shared memory.

And I think that IPC can be almost as fast as just writing to memory. If my IPC gives only a 5% overhead to a task switch (which it probably does), since threads need to do task switches too, it is only 5% slower than two threads. But then you also don't have to use things like mutexes (mutexen?) and semaphores, which can have significant overhead.

Single processes shouldn't need to scale to multiple processes, at least in the process model. You have multiple instances of a process running on separate processors and communicating with IPC instead. This is what is used for scientific calculations and supercomputing because threads are slow and complex - there's no argument that it doesn't scale. If you modularize, you get concurrency easily.

And I'm not sure how I missed that thread, syntropy. It seems like they all agreed that events were better, and tried to figure out how to implement continuations well - there's some really interesting stuff there...

It's definitely a very useful discussion. I only wish there was more of those quality threads on the forums.

I'm busy myself working on a theory and design that I believe thoroughly departs from conventional operating system design. I don't know exactly how to describe it but I think it will work. It's that same feeling where you see a mathematical equation and instantly 'see' the answer. You know that the result is correct but don't know exactly how you got to that conclusion. It's hard to explain, especially considering that I'm working on rough understandings of computational theory on my own through Wikipedia and online textbooks. Our local "higher" education is somewhat lacking in everything that doesn't involve manual labour and industry unfortunately.

I'm busy myself working on a theory and design that I believe thoroughly departs from conventional operating system design. I don't know exactly how to describe it but I think it will work. It's that same feeling where you see a mathematical equation and instantly 'see' the answer. You know that the result is correct but don't know exactly how you got to that conclusion. It's hard to explain, especially considering that I'm working on rough understandings of computational theory on my own through Wikipedia and online textbooks. Our local "higher" education is somewhat lacking in everything that doesn't involve manual labour and industry unfortunately.

Could you try and explain your idea? It seems like at least you are pretty excited about it, and I have no doubt it's interesting.

And I don't know if a "Wikipedia education" is all that bad for computer science - I'm just in high school, but it seems like all anyone is teaching nowadays is how to write bad Java to people who don't even understand how a computer works.

NickJohnson wrote:

I'm busy myself working on a theory and design that I believe thoroughly departs from conventional operating system design. I don't know exactly how to describe it but I think it will work. It's that same feeling where you see a mathematical equation and instantly 'see' the answer. You know that the result is correct but don't know exactly how you got to that conclusion. It's hard to explain, especially considering that I'm working on rough understandings of computational theory on my own through Wikipedia and online textbooks. Our local "higher" education is somewhat lacking in everything that doesn't involve manual labour and industry unfortunately.

Could you try and explain your idea? It seems like at least you are pretty excited about it, and I have no doubt it's interesting.

And I don't know if a "Wikipedia education" is all that bad for computer science - I'm just in high school, but it seems like all anyone is teaching nowadays is how to write bad Java to people who don't even understand how a computer works.

We need more people like you.

I'm busy myself working on a theory and design that I believe thoroughly departs from conventional operating system design. I don't know exactly how to describe it but I think it will work. It's that same feeling where you see a mathematical equation and instantly 'see' the answer. You know that the result is correct but don't know exactly how you got to that conclusion. It's hard to explain, especially considering that I'm working on rough understandings of computational theory on my own through Wikipedia and online textbooks. Our local "higher" education is somewhat lacking in everything that doesn't involve manual labour and industry unfortunately.

Sounds a lot like haskell. And we have a share of teachers here who think its THE future. (although I think that is a bit overrated). At least its well worth a look.

And I don't know if a "Wikipedia education" is all that bad for computer science - I'm just in high school, but it seems like all anyone is teaching nowadays is how to write bad Java to people who don't even understand how a computer works.

Over here, teaching cheap java tricks is done for the information scientists, who stubbornly refuse to think like a computer.
Not to mention, 20% of IS passes the programming course first time, compared to 80% of the CS students.

Combuster wrote:

I'm busy myself working on a theory and design that I believe thoroughly departs from conventional operating system design. I don't know exactly how to describe it but I think it will work. It's that same feeling where you see a mathematical equation and instantly 'see' the answer. You know that the result is correct but don't know exactly how you got to that conclusion. It's hard to explain, especially considering that I'm working on rough understandings of computational theory on my own through Wikipedia and online textbooks. Our local "higher" education is somewhat lacking in everything that doesn't involve manual labour and industry unfortunately.

Sounds a lot like haskell. And we have a share of teachers here who think its THE future. (although I think that is a bit overrated). At least its well worth a look.

Functional programming has it's good and bad points. I'm a pretty "no silver bullet" kind of guy, but if I had to put my money on a language paradigm (beyond just imperative), I would go with functional. Good, solid theory seems to always make the best programs, and functional languages are definitely the least heuristic of the bunch. Plus, without state, functional programs are the only ones that can really be threaded without using the locking systems that give so much complexity and overhead. They also lend themselves well to event driven systems, the way you guys were discussing them on the other thread. Still, I don't want to give up my global variables, pointers, and gotos, so I'm just sticking with C.

Combuster wrote: Over here, teaching cheap java tricks is done for the information scientists, who stubbornly refuse to think like a computer.
Not to mention, 20% of IS passes the programming course first time, compared to 80% of the CS students.

Yeah, it's getting pretty hard to find anyone who *doesn't* teach Java exclusively over here. I think there is like one respectable C course, which is online, and it's only up to things like linked lists and basic sorting (I think they also have an "advanced" Java course where you learn to use the graphic systems). At my school, which is considered to be really good (comparatively, of course), their idea of computer science is learning how to program tic-tac-toe in Java. They learn basic OO and the standard library, but never actually *how* the data structures they use work or how slow they are if used incorrectly. And that is the AP course - you can get actual college credit for that. Oh, well.

NickJohnson wrote:Yeah, it's getting pretty hard to find anyone who *doesn't* teach Java exclusively over here. I think there is like one respectable C course, which is online, and it's only up to things like linked lists and basic sorting (I think they also have an "advanced" Java course where you learn to use the graphic systems). At my school, which is considered to be really good (comparatively, of course), their idea of computer science is learning how to program tic-tac-toe in Java. They learn basic OO and the standard library, but never actually *how* the data structures they use work or how slow they are if used incorrectly. And that is the AP course - you can get actual college credit for that. Oh, well.

<rant>
If that's your opinion of a "good" school, try mine - Java is only the first course you get. Then you get this shitload of mathematics (covering discrete maths, integrals, differentials, complex numbers, recurrences, and basic vector and matrix theory with gauss elimination up to markov processes), which is when the majority of students quit. Next up is logic and set theory (which teaches you how to do binary math and proper proofs). then you get "system architecture and networks" (Which teaches you how CPUs, MMUs, paging and segmentation works, then goes on with basic assembly, inode based file management, process management, then all basic theory on computer networks). Then a whole course on just functional programming (w00t), one on databases (SQL, design, locking, optimisation, transactions and redundancy removal algorithms), and then the dreaded data structures course (lean to do complexity calculations, and know all the following by hard: stacks, queues, linked lists, arrays, doubly-linked lists, skip lists, 7 different sorting algorithms, and 4 tree structures). Then you have one option of specialisation, and you're done.

With the first of three years bachelor education.
</rant>

Well, I would take hard and interesting over easy and dumb any day.

Combuster wrote:If that's your opinion of a "good" school, try mine - Java is only the first course you get. Then you get this shitload of mathematics (covering discrete maths, integrals, differentials, complex numbers, recurrences, and basic vector and matrix theory with gauss elimination up to markov processes), which is when the majority of students quit. Next up is logic and set theory (which teaches you how to do binary math and proper proofs). then you get "system architecture and networks" (Which teaches you how CPUs, MMUs, paging and segmentation works, then goes on with basic assembly, inode based file management, process management, then all basic theory on computer networks). Then a whole course on just functional programming (w00t), one on databases (SQL, design, locking, optimisation, transactions and redundancy removal algorithms), and then the dreaded data structures course (lean to do complexity calculations, and know all the following by hard: stacks, queues, linked lists, arrays, doubly-linked lists, skip lists, 7 different sorting algorithms, and 4 tree structures). Then you have one option of specialisation, and you're done.

With the first of three years bachelor education.
</rant>

Seems pretty much like my university course (although I sucked at Markov chains and I hated Petri nets, and we also had some kind of signal processing and control theory). However you can't possibly argue that only teaching GUI programming in Java would be better... At least your course gives you insight into how computer and/or systems work. Also, if someone doesn't know what the structures are that you mentioned, that pretty much guarantees that he/she will fail at osdev.

Actually, I just found myself designing a simple PID controller the other day. I had never imagined that I would actually use that control theory stuff, but it came handy. And that's what the strength of your (or mine) course is - it gives you insight.

But this is getting way offtopic.

I switched from CS to compE because CS started getting too theoretical and not enough to do with computers. I'm glad I did, I'm an embedded software engineer now working on low level drivers.

Hello all,

I was reading this PDF discussing event vs. thread driven systems and it reminded me of this conversation. The paper is a bit dated (from 2003), but I think it is still relevant. The authors of the paper are pro-threading and argue that there is nothing inherently wrong with threads, only problems with how threads have been implemented. Further, they argue that working with threads can be made easier if the compliler/runtime can work together to do more to help the programmer (which sounds like OpenMP to me.)

Personaly, I am still undecided. Threads vs. Events may be one of those 'right tool for the right job' situations.

- TJ

P.S. Does anybody else think the benchmark in the paper is bogus?

That does seem like an interesting paper. I have no idea about the benchmarks' accuracy though.

I think it's pretty obvious that events, when the server is only one process, would not be as scalable as threads. However, you could have multiple heavyweight processes all handling events, and be able to increase your throughput as much as you like without having shared memory state. I think the best argument for using events is that events are much more powerful and efficient than any sort of polling method, and once information goes from event driven to polling, you can't make it go back. For example, if you had every IRQ simply set a bit to show that it fired, then polled all of those bits constantly, it would be much slower than real interrupts, and you could never get the efficiency of the interrupt back.