re progr a mming techniques, l a ngu a ge fe a tures, a nd system components th a t a llow multiple t a sks to execute concurrently while coordin a ting their a ccess to sh a red resources s a fely a nd e ff iciently. • Remember: Concurrency me a ns multiple t a sks c a n m a ke progress during overl a pping periods of time, whether on one CPU core (by interle a ving execution) or multiple cores (in p a r a llel).
d a t a time to a ccess a sh a red resource. ▶ synchronized (J a v a ). J a v a keyword th a t a utom a tic a lly locks methods or code blocks for thre a d-s a fe a ccess. ▶ Atomic Types (J a v a ). Performs simple oper a tions a s indivisible, thre a d-s a fe a ctions without explicit locks. 2. Sem a phore. Limits the number of thre a ds th a t c a n a ccess a sh a red resource simult a neously. 3. Thre a d Pool. Reuses a f ixed set of worker thre a ds to execute multiple t a sks e ff iciently.
one thre a d c a n a ccess a sh a red resource or critic a l section a t a time. Wh a t do they gu a r a ntee? • Mutu a l exclusion → only one thre a d holds the lock a t a time • Visibility → ch a nges a re visible when the lock is rele a sed • Explicit control → lock a cquisition a nd rele a se a re progr a mmer-m a n a ged When to use Locks? • When coordin a tion is required beyond synchronized • When locking a nd unlocking must h a ppen in di ff erent scopes
a v a .util.concurrent.locks • Lock (interf a ce) • Reentr a ntLock — most common implement a tion • St a mpedLock — high-perform a nce, non-reentr a nt re a d/write lock Python • import thre a ding • Lock — b a sic mutex lock • RLock — reentr a nt mutex lock • No built-in equiv a lent to St a mpedLock (or Re a dWriteLock)
keyword used to ensure th a t only one thre a d a t a time c a n execute a speci f ic piece of code or method. • It uses a lock implicitly Wh a t do they gu a r a ntee? • Mutu a l exclusion → only one thre a d enters the critic a l section • Visibility → ch a nges a re visible when the lock is rele a sed When to use synchronized? • Protecting multiple rel a ted v a ri a bles • Enforcing a ll-or-nothing upd a tes • When code cl a rity a nd correctness m a tter more th a n r a w perform a nce
is a v a ri a ble th a t c a n be s a fely modi f ied by multiple thre a ds without using locks or synchronized blocks. Wh a t do they gu a r a ntee? • Atomicity → no interle a ving during upd a tes • Visibility → ch a nges a re immedi a tely visible to other thre a ds • No locks → uses low-level CPU comp a re- a nd-sw a p (CAS) When to use Atomic types? • Sh a red counters, f l a gs, or simple st a te • High-contention scen a rios where locks would slow things down • When only one v a ri a ble must be protected
a resource by m a int a ining a f ixed number of permits. Thre a ds must a cquire a permit before proceeding a nd rele a se it when f inished. Wh a t do they gu a r a ntee? • Bounded a ccess → only a limited number of thre a ds m a y enter • Visibility → ch a nges a re visible when permits a re rele a sed • No ownership → permits a re not tied to a speci f ic thre a d When to use Sem a phores? • Limiting a ccess to a f inite resource (connections, printers, c a rts) • Throttling concurrency to a void overlo a d
m a nu a lly cre a ting or controlling thre a ds. Wh a t do they provide? • Thre a d reuse → a voids costly thre a d cre a tion • Concurrency control → limits how m a ny thre a ds run a t once • T a sk scheduling → queues a nd executes submitted t a sks • Sc a l a bility → a d a pts to multicore systems When to use it? • Running m a ny short-lived t a sks • Limiting p a r a llelism to a v a il a ble CPU cores
viergs/CSC364/tree/m a in/08-control Concurrency mech a nisms explored: • ExecutorService (thre a d pools) • Sem a phore (limited resources) • Reentr a ntLock (exclusive a ccess) • synchronized (sh a red st a te protection)
seline. Run the progr a m unch a nged. Observe output order a nd termin a tion. Expl a in wh a t e a ch concurrency mech a nism represents P a rt 1 – Sem a phore Experiments (C a p a city Limits). Modify sem a phore permits (1, 2, 3, 10, 50). Observe concurrency, w a iting, a nd execution time. Expl a in why incre a sing permits eventu a lly stops helping P a rt 2 – Removing Sem a phore Protection. Comment out a cquire() / rele a se() c a lls. Observe loss of resource limits. Expl a in the re a l-world bug being simul a ted P a rt 3 – Lock Misuse (De a dlock). Remove unlock() on a Reentr a ntLock. Observe h a ngs a nd incomplete t a sks. Expl a in why a single missing unlock c a n block the system P a rt 4 – Removing synchronized (R a ce Conditions). Remove synchroniz a tion from sh a red st a te upd a tes. Run multiple times a nd observe inconsistent results. Expl a in r a ce conditions using observed beh a vior P a rt 5 – Thre a ds vs CPU Cores. Detect a v a il a ble CPU cores. Experiment with pool sizes (½×, 1×, 2× cores)
Computing Javier Gonzalez-Sanchez, Ph.D. [email protected] Winter 2026 Copyright. These slides can only be used as study material for the class CSC 364 at Cal Poly. They cannot be distributed or used for another purpose. 45
javiergs
deanohume
portentint
lara
nikkihalliwell
bkeepers
chikuwait
axbom
pedronauck
cassininazir
lfama
erikaheidi
![Dr. Javier Gonzalez-Sanchez [email protected] www.javiergs.info o ffi ce: 14 -227](https://files.speakerdeck.com/presentations/ec9c94960a364fba8a76b05366be472a/slide_0.jpg){kind=link}
