|
|
Did you write all in less than 24 hours? 
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Saying it's "ridiculous" to start with is / was sort of invitation to fix it.
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
|
|
|
|
|
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> and SemaphoreSlim for my message queue. The semaphore is just to wake up a thread when messages become available.
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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() or SwingUtilities.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
|
|
|
|
|
... and I don't care. Never trust a computer that you have not misprogrammed yourself.
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
