Multithreaded code is ridiculous
-
So as an instructional article I'm preparing code that can enqueue work items to a limited number of threads. If all the threads are busy and there's no more thread creation allowed (say you have a 3 thread limit) then one of the threads that's already busy enqueues the next message for when it's done with what it's currently processing. It schedules among the already busy threads using a round robin technique. The whole thing works using message passing and message queues. That's how the threads communicate with each other. You can post messages to each of the threads. The trouble with it is the complexity of it snowballs. All of the sudden I need to sync the UI which requires a whole separate layer. And then there's the interthread communication that's already complicated. There's only so much I can fit into an article without overwhelming the reader, and to produce anything approaching a real world example requires so much complicated code that it's just silly. Oh you did this over here? Well you need to synchronize over there. And because you did that, you need to handle it over there too, etc. It's a mess. I really think the approach traditional computers take to preemptive multithreading is an anti-pattern. It feels like every anti-pattern I've ever encountered: The more code you need to make it work, the more code you need to make it work! You end up putting more work into it just to get to the point where you can put more work into it, and everything feels like a workaround.
Real programmers use butterflies
-
So as an instructional article I'm preparing code that can enqueue work items to a limited number of threads. If all the threads are busy and there's no more thread creation allowed (say you have a 3 thread limit) then one of the threads that's already busy enqueues the next message for when it's done with what it's currently processing. It schedules among the already busy threads using a round robin technique. The whole thing works using message passing and message queues. That's how the threads communicate with each other. You can post messages to each of the threads. The trouble with it is the complexity of it snowballs. All of the sudden I need to sync the UI which requires a whole separate layer. And then there's the interthread communication that's already complicated. There's only so much I can fit into an article without overwhelming the reader, and to produce anything approaching a real world example requires so much complicated code that it's just silly. Oh you did this over here? Well you need to synchronize over there. And because you did that, you need to handle it over there too, etc. It's a mess. I really think the approach traditional computers take to preemptive multithreading is an anti-pattern. It feels like every anti-pattern I've ever encountered: The more code you need to make it work, the more code you need to make it work! You end up putting more work into it just to get to the point where you can put more work into it, and everything feels like a workaround.
Real programmers use butterflies
Well, I'm a longstanding member of the choir that you're preaching to. :laugh: If it's a thread pool, I have them share a work queue. You seem to imply that you queue messages against threads even in this case, but I doubt it. I only queue messages on a thread when it's the only one handling that kind of work.
Robust Services Core | Software Techniques for Lemmings | Articles
-
So as an instructional article I'm preparing code that can enqueue work items to a limited number of threads. If all the threads are busy and there's no more thread creation allowed (say you have a 3 thread limit) then one of the threads that's already busy enqueues the next message for when it's done with what it's currently processing. It schedules among the already busy threads using a round robin technique. The whole thing works using message passing and message queues. That's how the threads communicate with each other. You can post messages to each of the threads. The trouble with it is the complexity of it snowballs. All of the sudden I need to sync the UI which requires a whole separate layer. And then there's the interthread communication that's already complicated. There's only so much I can fit into an article without overwhelming the reader, and to produce anything approaching a real world example requires so much complicated code that it's just silly. Oh you did this over here? Well you need to synchronize over there. And because you did that, you need to handle it over there too, etc. It's a mess. I really think the approach traditional computers take to preemptive multithreading is an anti-pattern. It feels like every anti-pattern I've ever encountered: The more code you need to make it work, the more code you need to make it work! You end up putting more work into it just to get to the point where you can put more work into it, and everything feels like a workaround.
Real programmers use butterflies
Been there, done that. And had my 3D stuff running in the background. UI and the 3D engine scripted with XAML.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
Well, I'm a longstanding member of the choir that you're preaching to. :laugh: If it's a thread pool, I have them share a work queue. You seem to imply that you queue messages against threads even in this case, but I doubt it. I only queue messages on a thread when it's the only one handling that kind of work.
Robust Services Core | Software Techniques for Lemmings | Articles
What I'm doing is I'm queuing up tasks. In the demo each time a user clicks a button (in order to queue up a new task) the code looks for an available worker. If it doesn't have one, and it can create a new one (and consequently a new thread) then it will. Otherwise if there are already a maximum number of workers created it will choose one of the busy workers to handle the next task. All of the workers do the same task. Think of this like a server application that accepts a limited number of incoming requests into a pool of workers, but will then queue requests after the limit is exceeded among the busy workers. One of them will pick it up as soon as it's finished with what it's doing. Make sense? I hope it does! :~ ETA: Wait, I think I see what you mean by using one queue. I'll have to think on this.
Real programmers use butterflies
-
Been there, done that. And had my 3D stuff running in the background. UI and the 3D engine scripted with XAML.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
Yeah, I mean, I can do it real world, but it's even harder to do it simple enough that it can be used to instruct. That's part of what my rant was about. :)
Real programmers use butterflies
-
Yeah, I mean, I can do it real world, but it's even harder to do it simple enough that it can be used to instruct. That's part of what my rant was about. :)
Real programmers use butterflies
Instructing? I have done a bit of that, but you would not like my methods. :-) Edit: I think, some of my instructors would also have loved to send me to the ghost guard. Tenty times. :-) (What Did You Say, Sergeant? - YouTube[^])
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
What I'm doing is I'm queuing up tasks. In the demo each time a user clicks a button (in order to queue up a new task) the code looks for an available worker. If it doesn't have one, and it can create a new one (and consequently a new thread) then it will. Otherwise if there are already a maximum number of workers created it will choose one of the busy workers to handle the next task. All of the workers do the same task. Think of this like a server application that accepts a limited number of incoming requests into a pool of workers, but will then queue requests after the limit is exceeded among the busy workers. One of them will pick it up as soon as it's finished with what it's doing. Make sense? I hope it does! :~ ETA: Wait, I think I see what you mean by using one queue. I'll have to think on this.
Real programmers use butterflies
You said you round-robin, which sounds fine for what you're doing. I use work queues because items aren't lost if a thread fails, there can be queues for different priorities, and some work items may take longer than others. None of these are issues for your demo, though.
Robust Services Core | Software Techniques for Lemmings | Articles
-
Instructing? I have done a bit of that, but you would not like my methods. :-) Edit: I think, some of my instructors would also have loved to send me to the ghost guard. Tenty times. :-) (What Did You Say, Sergeant? - YouTube[^])
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
Do they involve beating the stupid out of students? :-D
Real programmers use butterflies
-
You said you round-robin, which sounds fine for what you're doing. I use work queues because items aren't lost if a thread fails, there can be queues for different priorities, and some work items may take longer than others. None of these are issues for your demo, though.
Robust Services Core | Software Techniques for Lemmings | Articles
Well it turns out you were right, and I could get away with a single shared server queue in this case. Thanks for that. I guess I was just following a pattern without thinking hard enough about it. I use queues, but not priority queues because the code is already complicated enough. I could probably implement a thread safe priority queue but it's not something i want to do. ;P
Real programmers use butterflies
-
Do they involve beating the stupid out of students? :-D
Real programmers use butterflies
Only once. The idiot started to turn around to me with a loaded machine pistol in his hands. Safety set to 'A', as in 'Amen'. I edited the last post. The little video is funnier than this story.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
Well it turns out you were right, and I could get away with a single shared server queue in this case. Thanks for that. I guess I was just following a pattern without thinking hard enough about it. I use queues, but not priority queues because the code is already complicated enough. I could probably implement a thread safe priority queue but it's not something i want to do. ;P
Real programmers use butterflies
Just to clarify. I don't use a priority queue, but a separate queue for each priority level.
Robust Services Core | Software Techniques for Lemmings | Articles
-
Just to clarify. I don't use a priority queue, but a separate queue for each priority level.
Robust Services Core | Software Techniques for Lemmings | Articles
fair enough. :)
Real programmers use butterflies
-
So as an instructional article I'm preparing code that can enqueue work items to a limited number of threads. If all the threads are busy and there's no more thread creation allowed (say you have a 3 thread limit) then one of the threads that's already busy enqueues the next message for when it's done with what it's currently processing. It schedules among the already busy threads using a round robin technique. The whole thing works using message passing and message queues. That's how the threads communicate with each other. You can post messages to each of the threads. The trouble with it is the complexity of it snowballs. All of the sudden I need to sync the UI which requires a whole separate layer. And then there's the interthread communication that's already complicated. There's only so much I can fit into an article without overwhelming the reader, and to produce anything approaching a real world example requires so much complicated code that it's just silly. Oh you did this over here? Well you need to synchronize over there. And because you did that, you need to handle it over there too, etc. It's a mess. I really think the approach traditional computers take to preemptive multithreading is an anti-pattern. It feels like every anti-pattern I've ever encountered: The more code you need to make it work, the more code you need to make it work! You end up putting more work into it just to get to the point where you can put more work into it, and everything feels like a workaround.
Real programmers use butterflies
Yeah, that sounds wrong. One shared queue tends to work best.
-
Yeah, that sounds wrong. One shared queue tends to work best.
I ended up changing it so it did it with one queue. I just lost in engineering tunnel vision for a bit, though eliminating the individual pipelines means I lose control over who the message goes to.
Real programmers use butterflies
-
I ended up changing it so it did it with one queue. I just lost in engineering tunnel vision for a bit, though eliminating the individual pipelines means I lose control over who the message goes to.
Real programmers use butterflies
Threads are fungible.
-
Threads are fungible.
Most of the time, but in this case, one thread is potentially multifunction meaning for example, you might care about which one you stop since one might be doing a job you're still interested in! In the end I didn't go that route because it made everything too complicated for demonstration purposes.
Real programmers use butterflies
-
So as an instructional article I'm preparing code that can enqueue work items to a limited number of threads. If all the threads are busy and there's no more thread creation allowed (say you have a 3 thread limit) then one of the threads that's already busy enqueues the next message for when it's done with what it's currently processing. It schedules among the already busy threads using a round robin technique. The whole thing works using message passing and message queues. That's how the threads communicate with each other. You can post messages to each of the threads. The trouble with it is the complexity of it snowballs. All of the sudden I need to sync the UI which requires a whole separate layer. And then there's the interthread communication that's already complicated. There's only so much I can fit into an article without overwhelming the reader, and to produce anything approaching a real world example requires so much complicated code that it's just silly. Oh you did this over here? Well you need to synchronize over there. And because you did that, you need to handle it over there too, etc. It's a mess. I really think the approach traditional computers take to preemptive multithreading is an anti-pattern. It feels like every anti-pattern I've ever encountered: The more code you need to make it work, the more code you need to make it work! You end up putting more work into it just to get to the point where you can put more work into it, and everything feels like a workaround.
Real programmers use butterflies
Quote:
o as an instructional article I'm preparing code that can enqueue work items to a limited number of threads. If all the threads are busy and there's no more thread creation allowed (say you have a 3 thread limit) then one of the threads that's already busy enqueues the next message for when it's done with what it's currently processing. It schedules among the already busy threads using a round robin technique.
It's called a producer-consumer model and it's generally not so hard to handle. In most cases you need just one queue and all consumers feed from it. No rule that says a consumer cannot be a producer also. Consumers need to be polivalent meaning they know how handle any task that they pick from the queue. If you have task-oriented consumers that know how to do only one task (sometimes called fussy-eaters) you're beter off with multiple queues and and each consumer waits in the appropriate queue.
Mircea
-
Well it turns out you were right, and I could get away with a single shared server queue in this case. Thanks for that. I guess I was just following a pattern without thinking hard enough about it. I use queues, but not priority queues because the code is already complicated enough. I could probably implement a thread safe priority queue but it's not something i want to do. ;P
Real programmers use butterflies
These issues you are discussing related to multi-threaded programming really are a problem. It's amazing how it originally seemed like multi-threaded programming was the panacea but just became another problem. :) Because it is so difficult a new thing has arisen: The Actor Model. Basically, it is a way to say that you have some work that should be done and you set an Actor to doing that work. It will be done concurrently and then let you know when it is done. In this way the threading part is abstracted away. One of the main implementations of The Actor Model is called Akka (originally implemented on the JVM). But now there is a .NET Version[^]. That site has a pretty good overview explanation of it all. The Actor Model really does fix a lot of what is wrong with the multi-threaded world. Check it out and see what you think.
-
Well, I'm a longstanding member of the choir that you're preaching to. :laugh: If it's a thread pool, I have them share a work queue. You seem to imply that you queue messages against threads even in this case, but I doubt it. I only queue messages on a thread when it's the only one handling that kind of work.
Robust Services Core | Software Techniques for Lemmings | Articles
Greg Utas wrote:
Well, I'm a longstanding member of the choir that you're preaching to.
I agree. that's why if I had to do anything that really did heavy multi-threading (as a service or back-end type thing -- not just in a WinForm app) then I would use the new thing: Akka (which implements the Actor Model[^]. I've actually used it one time and it is quite amazing once you get past the learning curve. There's more on that landing page but read this quick summary that really is as good as it sounds.
Akka site says:
Actor Model The Actor Model provides a higher level of abstraction for writing concurrent and distributed systems. It alleviates the developer from having to deal with explicit locking and thread management, making it easier to write correct concurrent and parallel systems.
There are some nice simple diagrams there that show how it works.
-
So as an instructional article I'm preparing code that can enqueue work items to a limited number of threads. If all the threads are busy and there's no more thread creation allowed (say you have a 3 thread limit) then one of the threads that's already busy enqueues the next message for when it's done with what it's currently processing. It schedules among the already busy threads using a round robin technique. The whole thing works using message passing and message queues. That's how the threads communicate with each other. You can post messages to each of the threads. The trouble with it is the complexity of it snowballs. All of the sudden I need to sync the UI which requires a whole separate layer. And then there's the interthread communication that's already complicated. There's only so much I can fit into an article without overwhelming the reader, and to produce anything approaching a real world example requires so much complicated code that it's just silly. Oh you did this over here? Well you need to synchronize over there. And because you did that, you need to handle it over there too, etc. It's a mess. I really think the approach traditional computers take to preemptive multithreading is an anti-pattern. It feels like every anti-pattern I've ever encountered: The more code you need to make it work, the more code you need to make it work! You end up putting more work into it just to get to the point where you can put more work into it, and everything feels like a workaround.
Real programmers use butterflies
Some languages are more suitable for concurrrent programming, see: programming-languages-for-concurrent-programming[^]
