I'm starting to learn about concurrency programming/threading and was wondering about some good resources to start this journey. Concurrency requires a different method of thinking about problems than standard serial code, I'm aware.
So far, I've picked up The Art of Concurrency from O'Reilly and I've been Googling a little (but to not much avail, it seems that threading isn't much of a hobby among programmers and I can see why).
Applications of threading that I would be interested in would be things like timer threading for network timeouts and keeping all the code aware of this happening, design patterns, algorithms, etc. Thank you in advance.
Name:
Anonymous2009-08-26 3:53
timer threading for network timeouts
What do you mean?
Name:
Anonymous2009-08-26 3:53
Creating threads is quite simply on world4ch. At the bottom of the page is a "New Thread" form, where you fill in the details (subject title, post content, name and email). Right next to these fields is a post thread button, which is responsible for posting the thread.
Name:
Anonymous2009-08-26 3:58
The only relevant thing i know is a book called "The Art of Multiprocessor Programming".
Never read it, but i know it uses java
Name:
Anonymous2009-08-26 4:08
>>4
Ah, yes, there are a ton of books that are specifically in reference to Java, but I don't use Java and I'm not sure that the concepts would port elegantly to a more useful language for me. However, I would not be opposed to reading a book that's more about the concepts than the language implementation, even if it happened to use Java.
>>2
Handing network timeouts using a thread specifically dedicated to timer functions, rather than having the timer code eat up a ton of processing time on the main thread. Just an example of the types of things I'd like to learn - how to make threads play nice together.
Name:
Anonymous2009-08-26 5:03
yo dog i heard you like applications with a future, so i put java in your computer so you can program multithreaded applications that will not become absolute in 2 years.
>>8
I understand the underlying mechanisms and theory behind threading. That doesn't mean I know how to use them effectively and make them play nice with one another.
Processes are typically scheduled as threads in modern OSes and processing is halted at arbitrary points with a snapshot of the state and then the OS gives control to other threads. These context switches can happen at any time and the same idea applies to threads within a process.
Understanding this is an imperative building block, but not the whole picture. If you knew anything about threading, you would know that it's a lot more complicated than "trivial." IHBT.
>>7
It's not that simple, there's a ping/pong mechanism that has additional processing beyond simply terminating the connection. What I'm trying to do is find material that would teach me more about threading in general so I might design my example construct in a way that would not cause race conditions.
Implement your functions in a purely functional manner. Congratulations! Your program is now free of race conditions.
Name:
Anonymous2009-08-26 11:37
>>10
Fuck pthreads. In fact, fuck threading in general.
If you're in a position where multithreading offers an advantage over multiprocessing, you're using the wrong operating system.
The only real reason people push multithreading instead of multiprocessing is because shared state is implicit (and therefore ``easier'') with multithreading. These people are morons.
Name:
Anonymous2009-08-26 11:56
>>13
5/10. For more points, try to make your ad hominem more subtle and yet, more extravagant.
>>9 Understanding this is an imperative building block, but not the whole picture.
You're right, you just recited some inaccurate nonsense that doesn't really help.
If you knew anything about threading, you would know that it's a lot more complicated than "trivial."
I use threading effortlessly whenever it's helpful to the problem. It's fucking trivial. You won't fail at threads, you'll fail at everything else and then blame it on threads. Because you don't understand the goddamn system.
>>14
That wasn't actually a troll. I'd be more than willing to expand my argument if anyone's curious about some part of it.
There's a lot of religion in multithreading, and a lot of people invest a lot of time in strategies that are just wrong-headed, and since programming, being ``engineering'' rather than science, is ego-driven, a lot of people refuse to admit they've been wrong for years and will just keep pushing broken models. It's depressing.
Name:
Anonymous2009-08-26 12:55
>>16
Please do, multiprocessing works when your task is stupidly parallel, but not are problems are that simple.
Name:
Anonymous2009-08-26 12:58
>>17
I invite you to come up with a single thing multithreading can do multiprocessing cannot.
Most often I see people trying to force threading where it doesn't belong in the first place, like for asynchronous GUIs (spoiler: interrupts have been around for longer than threads).
Name:
Anonymous2009-08-26 13:51
Process creation is expensive. Why fork and set up some stupid IPC when I can make another thread?
>>19
If process creation is (much) more expensive than thread creation, your OS sucks.
In practice, of course, it isn't noticeable even for the worst offenders (that is, Windows and Solaris).
Name:
Anonymous2009-08-26 15:55
>>21
Varies. Basically and oversimplifiedly, the main difference tends to be that threads share address space.
Name:
Anonymous2009-08-26 18:31
>>18
Just because you can do something a certain way, does not mean it's an effective or good way to do it. The issue isn't whether or not multiprocessing CAN do the things that threading can do.
And you want to talk about religion in threading? It seems you subscribe to an alternate religion. >>17-san asked you to explain why multiprocessing offers advantages over threading. I believe it's possible that WHBT.
>>15
1/10. You gave up your subtlety in exchange for force. Next time, be less forceful and slightly more vague.
>>24 >>17-san asked you to explain why multiprocessing offers advantages over threading.
For one thing, a lack of implicit shared state, which eliminates a whole class of bugs right off the bat.
>>18 interrupts have been around for longer than threads
I don't see how you would use interrupts for managing GUIs, unless you're talking about different interrupts than I know about.
>>30 But both are managed by the OS, right?
In the sense that pretty much everything is managed by the OS. User-level threads (including pthreads in ``compliant'' implementations; that is, not Linux, which fakes it with processes) aren't even necessarily managed by the OS, though, and a pain in the ass in general.
I don't see how you would use interrupts for managing GUIs, unless you're talking about different interrupts than I know about.
I must be. I'm talking about the interrupts people who know what they're talking about use.
Name:
Anonymous2009-08-27 16:57
>>31 I'm talking about the interrupts people who know what they're talking about use.
Why are you mean to me :<
>>33
The point of standards bodies isn't to promote good technologies. It's to standardize. ``Development firms'' are also pushing Sepples and Java.
Your appeal to authority has been noted and dismissed.