A student wrote me with questions on concurrency. On the assumption that there are other students with these same questions, I've decided to share my answers with the rest of the class.
- When there is single processor, multiple threads, then its simulated parallelism.
Yes, there is concurrency but there is not true parallelism.
- When we have multiple processors, multithreads, then there is a potential for true parallelism to occur.
Yes, if we have multiple processors and a program using multiple threads then there is a potential for true parallelism to occur. As we've seen, it is up to the scheduler of the programming language's run-time. When I wrote a multi-threaded script in Ruby 1.9, I only received concurrency. Ruby's scheduler was not able to take advantage of the multiple processors on my laptop. However, when I wrote a multi-threaded program in Java, I received true parallelism. Java's scheduler was able to create the threads such that they ran on multiple processors at the same time.
- For sequential programming, we have single thread, single processor.
Better to say: for sequential programming, we have only a single thread of control. A sequential program can be run on a computer that has multiple processors but it will only ever make use of a single processor.
- Whats multitasking and timesharing? Is that common for all three, I mean, multitasking and time sharing is seen in all the three cases.? Why always the chapter starts from multitasking and proceeds to multithreading?
I'm not quite sure I understand your question but here goes.
Time sharing in computer systems is what I typically call simulated parallelism. The scheduler knows that it has three threads to run, so it runs thread 1 for a little bit, then runs thread 2 and then runs thread 3. Each thread makes progress over time, but only one is running at any one time.
A task is something that a concurrent program needs to perform. In one of my example programs, the task was to read an XML file and count the number of
tags within it. In that program, I created six threads to process files, one thread to read the files into memory, and one thread to send output to System.out (8 threads total). Each time the producer thread read in a file and stuck its contents on the queue, a task was created. Each time a consumer thread, pulled a file off the queue and processed it, a task was completed. I pointed that program at a directory that contained 40,000 XML files to process. So, when the program was running, it processed 40,000 tasks using 8 threads.
- How does the accuracy and performance in true parallelism differ from simulated parallelism? Can you elaborate this taking a scenario?
This is difficult to answer. You will get better performance with true parallelism if you have lots of independent tasks being processed by multiple threads, since all of the threads can run at the same time. If you have simulated parallelism, then you can still have lots of tasks and threads but the overall program will take longer to run because only one thread can run at a time.
The accuracy should be the same in both cases. The same code is executing, the only difference is how many threads are active at once.
- Last but not the least, now a days , there is dual/quad core processor with multithreading , in which case true parallelism occurs, which is also called concurrency. Right?
The author refers concurrency to case 1 and 2. am I right?
Yes, if you have a quad-core processor on your laptop, you have essentially four cpus that can be active at the same time. If you then right a program with multiple threads and those threads are assigned to the four cpus at the same time by the program's scheduler, then you get true parallelism. If the scheduler isn't set-up to handle parallelism (as is the case with ruby's scheduler) then you get simulated parallelism. Both programs would be considered a concurrent application.