Multithreaded code is ridiculous
-
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
-
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
I'm not saying it is. I'm simply saying that in order to demonstrate the whole shebang in a way that doesn't make the concepts specific to .NET required me to reinvent that particular wheel for demonstration purposes. Again I make it clear in the introduction that this approach is for demonstration, not for production, and suggest using the Task framework and the ThreadPool for this stuff.
Real programmers use butterflies
-
I'm not saying it is. I'm simply saying that in order to demonstrate the whole shebang in a way that doesn't make the concepts specific to .NET required me to reinvent that particular wheel for demonstration purposes. Again I make it clear in the introduction that this approach is for demonstration, not for production, and suggest using the Task framework and the ThreadPool for this stuff.
Real programmers use butterflies
-
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
That isn't the usual way of doing things; the common approach is: 1. Create pool of threads at startup (3, 5, whatever). 2. Create two queues at startup (work-queue and results-queue, using a LL or DLL queue, not an array). 3. Each thread takes the next work item from work-queue, working to completion, and posting the results to results-queue. 4. The main thread simply enqueues work items to the work-queue, and waits on the results-queue (use a semaphore here) for results. There's no blocking involved other than the wait-on-semaphore (and wait-on-mutex for queue modification).
-
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
Im having flashbacks now when I had to improve the throughput of some data processing application which I made a bunch of work on, so threaded it. Lucky c# task was a newish thing to me compared to previous time on threads which was doing separate thread class. but yeah figuring out the allocation was interesting. but yeah, one master queue using Synchronised List or Array makes the queue part much easier
-
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
Okay, I know I am late to the party here and might be a voice in the wilderness, but I think for your case, using manual multi-threading is exactly the right way to go. Why? Because you are teaching, students need to understand the complexity of the underlying functionality to be able to know when it is appropriate to use the simplified interfaces that modern languages, libraries, and syntactic sugar have added over the last thirty years. One of the things that I see in code that has been written by people who just discovered the async calls or the Thread library in whatever language is hot with management is the overuse of threads. They throw calls that are absolutely sure to block right here right now into a separate thread, even though processing on their application can not proceed without the answer. Hey folks, all of our operating systems and most of our language runtimes are smart enough to detect when some thread/process goes out for a long IO operation and let something else use the CPU. There is no need to add the overhead and complexity of putting your IO into a thread. On the other hand, beginners often miss thread operations in large complex compute operations. Activities where spinning the processing of a security token or hash into a temporary thread on a different core/processor thread with an async callback would let the other pre-authorized operations start rather than blocking on that operation. So, in addition to teaching them about the complexity of the dance that happens behind every simple thread spawn, you can also give them some views into the differences between appropriate and inappropriate times to use threads. Why the specific example is a teaching only example, and what real use-cases would be. Just a thought.
-
Okay, I know I am late to the party here and might be a voice in the wilderness, but I think for your case, using manual multi-threading is exactly the right way to go. Why? Because you are teaching, students need to understand the complexity of the underlying functionality to be able to know when it is appropriate to use the simplified interfaces that modern languages, libraries, and syntactic sugar have added over the last thirty years. One of the things that I see in code that has been written by people who just discovered the async calls or the Thread library in whatever language is hot with management is the overuse of threads. They throw calls that are absolutely sure to block right here right now into a separate thread, even though processing on their application can not proceed without the answer. Hey folks, all of our operating systems and most of our language runtimes are smart enough to detect when some thread/process goes out for a long IO operation and let something else use the CPU. There is no need to add the overhead and complexity of putting your IO into a thread. On the other hand, beginners often miss thread operations in large complex compute operations. Activities where spinning the processing of a security token or hash into a temporary thread on a different core/processor thread with an async callback would let the other pre-authorized operations start rather than blocking on that operation. So, in addition to teaching them about the complexity of the dance that happens behind every simple thread spawn, you can also give them some views into the differences between appropriate and inappropriate times to use threads. Why the specific example is a teaching only example, and what real use-cases would be. Just a thought.
Thomas Chizek wrote:
So, in addition to teaching them about the complexity of the dance that happens behind every simple thread spawn, you can also give them some views into the differences between appropriate and inappropriate times to use threads. Why the specific example is a teaching only example, and what real use-cases would be. Just a thought.
I already wrote the article my rant was about but this just might be fodder for a new article. Thanks. :)
Real programmers use butterflies
-
That isn't the usual way of doing things; the common approach is: 1. Create pool of threads at startup (3, 5, whatever). 2. Create two queues at startup (work-queue and results-queue, using a LL or DLL queue, not an array). 3. Each thread takes the next work item from work-queue, working to completion, and posting the results to results-queue. 4. The main thread simply enqueues work items to the work-queue, and waits on the results-queue (use a semaphore here) for results. There's no blocking involved other than the wait-on-semaphore (and wait-on-mutex for queue modification).
That's actually what I ended up doing. Greg Utas made a similar comment as you and I had an aha moment. Before that, I had engineering tunnel vision wherein I was stuck on doing something like I had imagined but there was an easier way. Still, the code, while much simpler is still ridiculous. :laugh: God bless the Task framework - of course using it this time would have defeated the purpose of what i was doing
Real programmers use butterflies
-
Thomas Chizek wrote:
So, in addition to teaching them about the complexity of the dance that happens behind every simple thread spawn, you can also give them some views into the differences between appropriate and inappropriate times to use threads. Why the specific example is a teaching only example, and what real use-cases would be. Just a thought.
I already wrote the article my rant was about but this just might be fodder for a new article. Thanks. :)
Real programmers use butterflies
No problem, glad to help. :)
-
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 don't know what language you're using but if using .NET much of your headache could be alleviated by using their threading library. The Parallel class takes care of the mundane management of threads and tries to abstract it away. It has methods for looping like Parallel.For where it will allocate a thread for each loop according to what is available. The library tries to optimise the best use of threads according to the system it is running on.
-
I don't know what language you're using but if using .NET much of your headache could be alleviated by using their threading library. The Parallel class takes care of the mundane management of threads and tries to abstract it away. It has methods for looping like Parallel.For where it will allocate a thread for each loop according to what is available. The library tries to optimise the best use of threads according to the system it is running on.
Yeah but I'm teaching concepts so I'm trying to avoid high level abstractions over threads.
Real programmers use butterflies
-
Im having flashbacks now when I had to improve the throughput of some data processing application which I made a bunch of work on, so threaded it. Lucky c# task was a newish thing to me compared to previous time on threads which was doing separate thread class. but yeah figuring out the allocation was interesting. but yeah, one master queue using Synchronised List or Array makes the queue part much easier
I used
ConcurrentQueue<T>andSemaphoreSlimfor my message queue. The semaphore is just to wake up a thread when messages become available.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
If you're having these issues you're doing it wrong. Multi-threaded code requires careful thought about how the threads, including the UI thread, will interact. It sounds to me like you're not thinking through thread interaction and just spending the time writing examples. If you want to teach this you must teach how to think about the problem first. I've written applications that scale to the number of processors - no more, no less, and this scaling required zero changes in the code once properly implemented. The same goes for UI interactions. The reason this worked is because I thought about the inter-thread communications before writing a single line of production code. Yes, I tested several possible options before committing to a model, but that's part of the thought process. Is multi-threaded code harder to write? By all means yes. Does this mean it needs to be super complex? Definitely not!
-
If you're having these issues you're doing it wrong. Multi-threaded code requires careful thought about how the threads, including the UI thread, will interact. It sounds to me like you're not thinking through thread interaction and just spending the time writing examples. If you want to teach this you must teach how to think about the problem first. I've written applications that scale to the number of processors - no more, no less, and this scaling required zero changes in the code once properly implemented. The same goes for UI interactions. The reason this worked is because I thought about the inter-thread communications before writing a single line of production code. Yes, I tested several possible options before committing to a model, but that's part of the thought process. Is multi-threaded code harder to write? By all means yes. Does this mean it needs to be super complex? Definitely not!
Funny, I got it working. And it works well. It's still ridiculous.
Real programmers use butterflies
-
That's actually what I ended up doing. Greg Utas made a similar comment as you and I had an aha moment. Before that, I had engineering tunnel vision wherein I was stuck on doing something like I had imagined but there was an easier way. Still, the code, while much simpler is still ridiculous. :laugh: God bless the Task framework - of course using it this time would have defeated the purpose of what i was doing
Real programmers use butterflies
Yeah, multi-threading is a pain in the rear. Concurrent processing and parallel processing in general is a pain in the rear, so it's usually best to go with some common idiom. Every single time I invented my own method of managing threads/tasks/processes I've regretted it. Shared-memory concurrency is painful; my best experiences with parallel computations were on Erlang. Using those idioms in my projects in other languages made my life a great deal easier, and now I no longer worry about parallel computations because I skip the shared-memory approach altogether.
-
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
Is very important like multithread is used: language, instructions and function. For example, with C++ into a Win32(IDE Visual Studio), with omp instruction and loop function, concurrency take a single thread for settings, like number of cores available and number of thread that need. Into this loop, a "do", this threads not take consequential way(and number into "do", the same) but seem random, also not really random, because depend like thread work
-
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 know the java UI (Swing) tries to simplify the UI thread sync issue by having everything run in the event dispatcher thread (using
SwingUtilities.invokeLater()orSwingUtilities.invokeAndWait()), so all the UI updates are done in the same thread. I don't know if using something similar would apply in your case. -
I know the java UI (Swing) tries to simplify the UI thread sync issue by having everything run in the event dispatcher thread (using
SwingUtilities.invokeLater()orSwingUtilities.invokeAndWait()), so all the UI updates are done in the same thread. I don't know if using something similar would apply in your case.I am not weighing in how Java does things, to be just to be clear. I don't know anything about it except how to read and write a little Java code. Also, I don't know that the way Swing does things is even "good". ETA: Or is what you're saying that .NET is doing something similar? I just caught that, sorry. I think they are, at least with respect to the task framework.
Real programmers use butterflies