Tag Archives: concurrency

[2022 javaone] hands on lab project loom

Posted on by
Reply

Facilitated by Oracle (Nicolai/Jose)

For more see the table of contents

Overview

  • The lab uses Oracle’s cloud environment. Setup was clear and well documented.
  • It’s a throwaway env only good for a few hours so you don’t have to worry about cleanup.
  • Can also do locally if prefer

Links

  • Workshop: https://bit.ly/ocw22-hol3733
  • https://github.com/JosePaumard/2022_javaone-loom-livelab.git

Virtual Threads

  • A virtual thread runs on a “real” platform thread called a carrier thread
  • Can be mounted/dismounted from carrier thread when blocks
  • It’s cool seeing a platform thread run so many virtual threads

Structured Concurrency

  • I just skimmed this part (had ice cream and got distracted talking to people so didn’t do the code for this half.) Conveniently, it is in github and I can do it in the future. Probably when it makes it out of incubator so I don’t forget everything.

My take

It took almost half an hour to get started. The online editor doesn’t work in Mac Safari so did the setup twice. I could have used Java 19 locally, but wanted to see what the lab environment looked like. I had enough time though so it was ok.’

I got to use single file source code execution (the lab didn’t say to, but less typing.) Must tease someone about its usefulness. And I got to to try out Loom.

[2020 devnexus] synchronized is obsolete

Posted on by
Reply

Speaker: Enrique Zamudio

For more, see table of contents

Classes

  • AtomicInteger
    • incrementAndGet()
    • compareAndSet()
  • AtomicReference
    • updateAndGet()
  • ConcurrentHashMap – methods on Map, but happens atomically
    • computeIfAbsent()
    • merge()
  • ConcurentSkipListMap
  • ConcurrentSkipListSet
  • LinkedBlockingQueue
    • Can take elements and deliver elements concurrently.
    • Every element delivered to exaclty one consumer
    • Unblocks consumers as long as something in queue
  • Locks – Lock, ReadWriteLock, ReentrantLock, CountDownLatch, CyclicBarrier, Semaphore, Phaser
    • ReentrantLock – execute code if can acquire lock
    • lock()
    • tryLock()
    • tryLock(10, SECONDS)
    • unlock()
  • Akka – project that implements Actor paradigm
  • vert.x – project for reactive – do things in single thread
  • Project Loom – lightweight threads. I thread takes 100MB just to exist; Project Loom is more like 2KB. Also no context switching.

Multiple processes

  • multiple copies of your jar
  • multiple vms with load balancer
  • synchronized or lock fails because each process can run code at same time
  • Can use database select … for update in database transaction so outside your process.
  • Similarly can use redis to set a lock with a random value. If the value matches, you know the lock is yours. If JVM crashes, lock stays. Can add lock timeout to avoid this
  • FencedLock – developed by Hazelcast Raft consensus model.

My take

I feel like I re-learn this topic every time I read the chapter in our book. (Scott wrote the chapter). I’m glad I went to this session. The more times I hear this, the more sticks. I had forgotten the project loom info so was definitely good to hear that again. The part about multiple processes was mostly new to me. (I just new about select for update)

[2019 oracle code one] java concurrency

Posted on by
Reply

Java Concurrency, A(nother) Peak Under the Hood

Speakers: David Buck (Oracle) – @DavidBuckJP

For more blog posts, see The Oracle Code One table of contents

Multi threaded code use cases

  • GUIs
  • Libraries
  • Batch Processing
  • Worst case: writing multi-threaded code but don’t know you are

Problems

  • Race conditions
  • Heisenbugs/observer problem – occur in Prod (or locally), but disappear in debugger

Tools

  • Java memory model
  • synchronized keyword
  • java.util.concurrent

Memory model

  • What guarantees do you have that writes in one thread are available to another thread?
    • Local variables safe
    • Static variables/instance variables can introduce concurrency problems
    • JIT compiler can change order things are done (vs the order you code them in)
    • If optimizing compiler sees a = 1 and a=a+1, compiler will just initialize a to 2.
    • Out of order execution – hardware can execute out of order to improve performance
  • Clartify what multithreaded behavior developers may depend on. Limits what types of optimizations the runtime can do
  • Spec: https://docs.oracle.com/javase/specs/jls/se13/html/jls-17.html

Things Java Protects us from

  • Testing on Raspberry Pi because ARM so can see problems that don’t occur on Intel chips
  • memory barrier/fence
  • prevents reordering before before/after fence. How do to this varies by processor./tool chain. Need to set two – one on read and one on write to guarantee behavior for testing.
  • Types: store-store, store-load, load-store, load-load

Relativity

  • As in physics, no single “correct” timelines
  • Observed order of events depends on frame of reference
  • Each core can have slightly different view of memory
  • This means core files aren’t 100% accurate

Changes to memory model

  • Originally only dealt with synchronized – mutual exclusion and happened-before. Volatile was defined but just about visibility
  • This was a problem because volatile didn’t enforce happened-before and final values could change.
  • Java 5 adopted Doug Lea’s open source APIs (JSR-166)
  • JSR-133 – ensured volatile does establish happens-before and final values will never changed
  • Volatile != atomic
  • id++ still not thread safe on a volatile field. Can use synchronized to fix
  • In original memory model, 64-bit numbers (longs and doubles) not updated atomically

Practical advice

  • Use highest level construct available. java.util.concurrency > synchronized/wait/notify. Last choice is volatile/final
  • Don’t roll your own. Even Doug Lea didn’t get it perfect
  • Java 8 – Lambdas/streams – high level
  • Java 9 – Var handles – lower level than volatile/final. Alllows value to be volatile only when we want it to be. Explicit fence/acquire/release. This was introduced for use cases sun.misc.Unsafe used to deal with.

My take

This was really interesting. It was like a peek behind the curtain! My only complain is that dark red text on a black background is hard to read. Luckily there wasn’t much of it and it was obvious what was being “emphasized” in red. Also, I liked the demos!