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
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[^]
-
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
Personally I find multithreading to be quite interesting and I don't have problems with it at all. Multiprocessing systems are also amusing. Throw in multiple processes each with multiple threads and it's great fun. Now I am working with CUDA and using literally thousands of threads. 2,304 on this laptop.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
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.
And what if it is not in .Net? ;) :rolleyes:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
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
I figured out a better way to do it as I was coding it anyway. :)
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
I hope I didn't trigger this :rolleyes: ;P
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
I hope I didn't trigger this :rolleyes: ;P
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
You sort of did, but the truth is i was looking for something to code anyway. At any rate I made this: A Thread Pooling and Task Queuing Demonstration Using Message Passing[^] It's not exactly what you were looking for, i think? but it might be closer. :)
Real programmers use butterflies
-
You sort of did, but the truth is i was looking for something to code anyway. At any rate I made this: A Thread Pooling and Task Queuing Demonstration Using Message Passing[^] It's not exactly what you were looking for, i think? but it might be closer. :)
Real programmers use butterflies
Did you write all in less than 24 hours? :omg: :omg:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
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.
I'm guessing I've open-sourced something similar in C++. - Software Techniques for Lemmings[^] describes the general principles. - Robust C++: P and V Considered Harmful[^] describes how critical sections are minimized. - Session Processing Tutorial[^] describes the state machine framework, which might be a "double-click" on what some refer to as the Actor pattern. All these concepts are used in the call servers that run in AT&T's wireless network.
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
Sounds useful. ThreadPool Class (System.Threading) | Microsoft Docs[^]
-
And what if it is not in .Net? ;) :rolleyes:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
Nelek wrote:
And what if it is not in .Net?
Well, then, it is obviously in Java --> Akka: build concurrent, distributed, and resilient message-driven applications for Java and Scala | Akka[^] :rolleyes: :rolleyes: Yeah, if it's not in either of those two then you must do all the work...or remove the multi-threaded sections of the code. :laugh:
-
Sounds useful. ThreadPool Class (System.Threading) | Microsoft Docs[^]
Yeah but there's issues using that, including not being able to control the number of threads it uses.
Real programmers use butterflies
-
Did you write all in less than 24 hours? :omg: :omg:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
Yes
Real programmers use butterflies
-
Yeah but there's issues using that, including not being able to control the number of threads it uses.
Real programmers use butterflies
-
I was wrong, fair enough but the other issue is I was demonstrating how thread pooling works, and using the ThreadPool and Task undermines all of that. I say as much at the beginning of the article.
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
A single ConcurrentQueue (serial) or a ConcurrentBag (random) for messages, and a BackgroundWorker for dispatching worker threads and updating the UI (progress reporting event).
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
A single ConcurrentQueue (serial) or a ConcurrentBag (random) for messages, and a BackgroundWorker for dispatching worker threads and updating the UI (progress reporting event).
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
I'm using a concurrent queue but i'm not using the BackgroundWorker nor the Task framework in my example, because the goal was to illustrate how the threading stuff works under the hood, not to provide production code. I say about as much in the introduction of the article.
Real programmers use butterflies
-
I'm using a concurrent queue but i'm not using the BackgroundWorker nor the Task framework in my example, because the goal was to illustrate how the threading stuff works under the hood, not to provide production code. I say about as much in the introduction of the article.
Real programmers use butterflies
ConcurrentQueue is not exactly a "primitive". About as primitive as BGW, IMO. And BGW is very fine-grained.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
