Background on Java Concurrency and Parallelism

[@abcabc-ur3bf]

This is the most clearer explanation on the difference between Concurrency and Parallelism in simple english. This channel is so underrated!

[@DouglasSchmidt]

Thanks very much - please share this channel with your colleagues!

[@ruixue6955]

3:22 threads can interact with each other via: 3:28 *shared objects* or *shared memory* and *message passing*
4:04 key goal: avoid race condition
6:19 parallelism
8:22 keep in mind
11:18 history
12:16 built-in monitor objects
13:33 pros and cons
13:48 Java 1.5
15:58 Java 1.7

[@sivaa1528]

Concurrency is a design where you structure your program into different tasks in a way that, if you run them sequentially or in parallel mode, the final result of the program will remain same. It is independent of the threads, you can run it on single core (or) multi-core the result of program will be same. Concurrency is a way to deal the things whereas Parallelism is a way to do the things.

[@qwe123727]

Prof Doug, For interactions between actors, when to prefer "send(msg)"/"recv(msg)" over get()/put() on shared object?

[@DouglasSchmidt]

Ethashamuddin, it all depends on what level of abstraction you're working at. For example:
. If you're Doug Lea (see th-cam.com/video/sq0MX3fHkro/w-d-xo.html), who writes lots of low-level java.util.concurrent classes you'll need to use the shared object mechanisms (e.g., CASs in sun.misc.unsafe that read/write to fields atomically).
. If you're developing higher-level frameworks (such as the Android AsyncTask or HaMeR frameworks or Java ExecutorCompetionService) you'll likely use a lot of message passing mechanisms (e.g., Android MessageQueues/Messages or Java LinkedBlockingQueues).
. If you're an application developer then you'll probably not want to use either shared objects or message passing, but instead you'll want program with higher-level frameworks (such as Java 8 parallel streams and completable futures or RxJava) that shield you from all the tedious and error-prone details of interacting between threads.
If you watch the rest of the videos in my class at www.dre.vanderbilt.edu/~schmidt/cs891/ you'll learn all about this stuff!
Doug

[@qwe123727]

Douglas Schmidt am going thru CS 891 and Cs 892

[@SanjeevKumar-hj1fb]

Prof Doug,
I was trying to understand your point where you said that if we use Java 8 constructs, you don't have to learn low level synchronization constructs(Locks/Synchronizers). I am having difficulty in understanding this. If we have to write the various concurrent data structures(ConcurrentHashMap,BlockingQueue etc) we have to use locks and synchronizers.
How the Java 8 helps in that case?
Regards,
Sanjeev

[@DouglasSchmidt]

Sandeep, I think you and I have discussed this before.. ;-) At any rate, here's the deal:
1. It's always useful to learn low-level synchronization constructs - just like it's always useful to know how to program in assembly code. However, if you learn Java 8 concurrency/parallelism frameworks (e.g., parallel streams and completable futures) you rarely need to *apply* low-level synchronization constructs in your programs, which is a "Good Thing"[TM].
2. For concrete illustrations of my point in #1 above, check out
github.com/douglascraigschmidt/LiveLessons/tree/master/Folder
github.com/douglascraigschmidt/LiveLessons/tree/master/ImageStreamGang
github.com/douglascraigschmidt/LiveLessons/tree/master/SearchStreamForkJoin
github.com/douglascraigschmidt/LiveLessons/tree/master/SearchStreamGang
github.com/douglascraigschmidt/LiveLessons/tree/master/SearchStreamSpliterator
and you'll see lots of concurrent/parallel programs written in Java 8 that use no low-level synchronization constructs.
3. Naturally, if you do need to write concurrent data structures knowledge of low-level synchronization mechanisms is important. However, very few people (aside from Doug Lea) need to know how to write concurrent data structures.. The vast majority of app developers are therefore better off learning how to use the higher-level Java 8 concurrency/parallelism frameworks than wrestling with low-level synchronization constructs. Even fewer people need to learn how to deal with even lower-level stuff like safe publication techniques..
Doug

[@SanjeevKumar-hj1fb]

Thanks Prof Doug for clarification. Yes, we discussed this before but I misunderstood your point and interpreted that we don't need to learn low level synchronization constructs, but your point was more towards their limited applications after Java8.

[@petervan7372]

why do you need synchronize/lock ConcurrentHashMap or BlockingQueue?