137
If it is truly a 1 in 10^55 event, there would be no need to code for it. That would imply that if you did the operation 1 million times a second, you'd get one bug every 3 * 10^41 years which is, roughly, 10^31 times the age of the universe. If your application has an error only once in every trillion trillion billion ages of the universe, that's probably ...
111
First of all, threads cannot speed up execution of code. They do not make the computer run faster. All they can do is increase the efficiency of the computer by using time that would otherwise be wasted. In certain types of processing this optimization can increase efficiency and decrease running time.
The simple answer is yes. You can write any code to be ...
102
A Fiber is a lightweight thread that uses cooperative multitasking instead of preemptive multitasking. A running fiber must explicitly "yield" to allow another fiber to run, which makes their implementation much easier than kernel or user threads.
A Coroutine is a component that generalizes a subroutine to allow multiple entry points for suspending and ...
93
A thread pool is a group of pre-instantiated, idle threads which stand ready to be given work. These are preferred over instantiating new threads for each task when there is a large number of short tasks to be done rather than a small number of long ones. This prevents having to incur the overhead of creating a thread a large number of times.
...
92
It is extremely important.
What is more important though is to understand that multithreading is just one way to solve the asynchrony problem. The technical environment in which many people are now writing software differs from the historical software development environment (of monolithic applications performing batch computations) in two key ways:
Many-...
84
After having been in this crazy business since about 1978, having spent almost all of that time in embedded real-time computing, working multitasking, multithreaded, multi-whatever systems, sometimes with multiple physical processors, having chased more than my fair share of race conditions, my considered opinion is that the answer to your question is quite ...
84
The operating system offers time slices of CPU to threads that are eligible to run.
If there is only one core, then the operating system schedules the most eligible thread to run on that core for a time slice. After a time slice is completed, or when the running thread blocks on IO, or when the processor is interrupted by external events, the operating ...
70
1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is.
At the moment, it sounds like you're simply "adding threads" to the language and worrying about how to make it correct and performant later. In particular:
if two tasks try to access a variable ...
69
From the cost-benefit standpoint, you should write additional code only when it gets you enough benefit.
For example, if the worst thing that would happen if a wrong thread "wins the race" is that the information would not display, and the user would need to click "refresh", don't bother guarding against the race condition: having to write a lot of code is ...
65
I'm only a casual Go user, so take the following with a grain of salt.
Wikipedia defines green threads as "threads that are scheduled by a virtual machine (VM) instead of natively by the underlying operating system". Green threads emulate multithreaded environments without relying on any native OS capabilities, and they are managed in user space instead of ...
58
If cooling is insufficient, the CPU might overheat. But they all (well, at least all modern PC CPUs) feature various thermal protection mechanisms which will throttle the clock speed or, as a final resort, shut down.
So yes, on a dusty laptop, 100 % CPU load could cause temporary problems, but nothing will break or "degrade" (whatever that means).
For CPU ...
46
It is getting ever more important as modern processors have more and more cores. A decade ago most of the existing computers had only a single processor, so multithreading was important only on higher-end server applications. Nowadays even basic laptops have multicore processors. In a few years even mobile devices... So more and more code is required to use ...
46
One assumption you are making might not be valid: you require (among other things) that your threads execute simultaneously. Might work for 3, but at some point the system is going to need to prioritize which threads to run first, and which one wait.
Your implementation will ultimately depend on your API, but most modern APIs will let you tell in advance ...
45
Finding a race condition is the hard part. You probably spent almost as much time writing this question as it would have taken you to fix it. It's not like it makes it that much less readable. Programmers expect to see synchronization code in such situations, and actually might waste more time wondering why it's not there and if adding it would fix their ...
45
It may be possible to do this "by accident" with careless use of core affinity. Consider the following pseudocode:
start a thread
in that thread, find out which core it is running on
set its CPU affinity to that core
start doing something computationally intensive / loop forever
If you start four of those on a two-core CPU, then either something goes wrong ...
37
What can multiple threads do that a single thread cannot?
Nothing.
Simple proof sketch:
[Church-Turing Conjecture] ⇒ Everything that can be computed can be computed by a Universal Turing Machine.
A Universal Turing Machine is single-threaded.
Ergo, everything that can be computed can be computed by a single thread.
Note, however, that there is a big ...
37
TL;DR Assumption ("contract") of spurious wakeups is a sensible architectural decision made to allow for realistically robust implementations of thread sheduler.
"Performance considerations" are irrelevant here, these are just misunderstanding that became widespread because of having stated in a published authoritative reference. (authoritative references ...
35
This is an oddly phrased question that is really, really broad if answered fully. I'm going to focus on clearing up some of the specifics that you're asking about.
Immutability is a design trade off. It makes some operations harder (modifying state in large objects quickly, building objects piecemeal, keeping a running state, etc.) in favor of others (...
35
A lot of programs (especially games) inherently use concurrency,
No, actually it's the reverse. Most apps are written in a single threaded mindset, and the developer(s) never made the necessary changes to support concurrency.
In C, C++, and C# you need to explicitly tell the application to start new threads and / or processes.
I think you're focusing ...
35
Is it impossible, or just plain unlikely?
Impossible. It can be implemented in different ways, e.g., via the Compare-and-swap where the hardware guarantees sequential execution. It can get a bit complicated in presence of multiple cores or even multiple sockets and needs a complicated protocol between the cores, but this is all taken care of.
34
You have multiple cores/procesors, use them
Async is best for doing heavy IO bound processing but what about heavy CPU bound processing?
The problem arises when single-threaded code blocks (ie gets stuck) on a long-running process. For instance, remember back when printing a word processor document would make the whole application freeze until the job was ...
34
It could be necessary to have 4 cores because the application runs four tasks in parallel threads and expects them to finish almost simultaneously.
When every thread is executed by a separate core and all threads have the exact same computational workload, they are quite likely (but far from guaranteed) to finish roughly the same time. But when two threads ...
32
This is best illustrated with an example.
Suppose we have a simple task that we want to perform multiple times in parallel, and we want to keep track globally of the number of times that the task has been performed, for example, counting hits on a web page.
When each thread gets to the point at which it's incrementing the count, its execution will look ...
31
The Fowler Article providers a good primer, and this explanation:
At a crude level you can think of a Disruptor as a multicast graph of
queues where producers put objects on it that are sent to all the
consumers for parallel consumption through separate downstream queues.
When you look inside you see that this network of queues is really a
single ...
29
I remember the JVM abandoning green threads and moving to native threads. This was for two simple reasons: the green threads were frankly rubbish, and there was a need to support multi-core processors with the limited developer effort available at Sun.
This was a shame - green threads provide a far better abstraction, allowing concurrency to be a useful ...
29
I am making a little program, which have few Threads, constantly running. At some point, I may want to stop one of them, and then, after random period of time, to start it again. What is the best way to create a thread?
The best way is to not do it at all. If I have work that needs to be done in parallel to another program, the best practice is to start ...
28
In general, multi-threading is already quite important, and is only going to get more important in the next few years (as Péter Török) pointed out - it is how processors will scale for the forseeable future (more cores instead of higher MHz).
In your case, however, you seem to be working mainly with web applications. Web applications, by their nature, are ...
28
Answer to the Question
The general consensus is shared mutable state is Bad™, and immutable state is Good™, which is proven to be accurate and true again and again by functional languages and imperative languages as well.
The problem is mainstream imperative languages are just not designed to handle this way of working, things aren't going to change for ...
28
The operating system provides certain primitives for this kind of interprocess communication that don't require polling.
If process A is waiting on mutex M, the OS knows A can't be run and puts it aside in a bucket of processes waiting for something to happen. When the process holding M releases it, the OS looks at the list of processes waiting for it. ...
28
Good concurrency requires a lot more than throwing a few threads in an application and hoping for the best. There's a range in how concurrent a program can be going from embarrassingly parallel to pure sequential. Any given program can use Amdahl's law to express how scalable a problem or algorithm is. A couple qualifications for a embarrassingly parallel ...
Only top voted, non community-wiki answers of a minimum length are eligible
