From 8d9a77c2e70f1a46c8b16aca14108e726cc61783 Mon Sep 17 00:00:00 2001 From: Andrew Myers Date: Mon, 11 Nov 2024 21:17:32 -0500 Subject: [PATCH] defined terms are supposed to be --- lectures/concurrency/index.html | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/lectures/concurrency/index.html b/lectures/concurrency/index.html index 16c66b4..242b8f3 100644 --- a/lectures/concurrency/index.html +++ b/lectures/concurrency/index.html @@ -173,7 +173,7 @@

Priorities and preemption

Daemon and normal threads

-A thread is either a daemon or a normal thread. +A thread is either a daemon or a normal thread. Daemon threads are used for minor or ephemeral tasks such as timers or sounds. The initial thread (the one that runs main) is normal. The application halts when either System.exit(...) is called or all @@ -265,7 +265,7 @@

Race conditions

be interrupted by another thread. This does not mean that when one thread executes, say, withdraw(), that all other threads are suspended. However, it does mean that as far as the programmer is concerned, the system -acts as if this were true. +acts as if this were true.

Critical sections and atomicity

@@ -350,7 +350,7 @@

Mutexes and synchronized

most one thread at a time.

-Threads can acquire them and release mutexes. +Threads can acquire them and release mutexes.

acquire: When a thread tries to acquire a mutex, it first checks whether @@ -447,7 +447,7 @@

Mutex syntactic sugar

Mutex variations

-Java mutexes are reentrant mutexes, meaning that it is harmless for a +Java mutexes are reentrant mutexes, meaning that it is harmless for a single thread to acquire the same mutex more than once. One consequence is that one synchronized method can call another on the same object without getting stuck trying to acquire the same mutex. Each mutex keeps track of the number of @@ -455,9 +455,9 @@

Mutex variations

once it has been released by the holding thread the same number of times.

-A locking mechanism closely related to the mutex is the semaphore, +A locking mechanism closely related to the mutex is the semaphore, named after railway -semaphores. A binary semaphore acts just like a (non-reentrant) +semaphores. A binary semaphore acts just like a (non-reentrant) mutex, except that a thread is not required to hold the semaphore in order to release it. In general, semaphores can be acquired by up to some fixed number of threads, and additional threads trying to acquire it block until some @@ -503,7 +503,7 @@

When is synchronization needed?

an inconsistent view of their contents.

Synchronization is also needed when we need to make sure that one -thread sees the updates caused by another thread. It is possible +thread sees the updates caused by another thread. It is possible for one thread to update an instance variable and another thread to later read the same instance variable and see the value it had before the update. This inconsistency arises because @@ -528,7 +528,7 @@

When is synchronization needed?

What possible values of y might be printed by Thread 2? Naively, it looks like the only possible value is 1. But without synchronization, Thread 2 could -observe the update to x before the update to y. +observe the update to x before the update to y. The fact that Thread 1 assigned to y before it assigned 1 to x does not matter! This behavior can and does happen frequently with modern hardware. This bizarre state of affairs shows that programming with @@ -548,7 +548,7 @@

When is synchronization needed?

change at any time. Any invariant that involves the value of such a field cannot be relied upon.

-Note that immutable state shared between threads doesn't need +Note that immutable state shared between threads doesn't need to be locked because it cannot be updated. This fact encourages a style of programming that avoids mutable state.