Topic: asynchronous processing
Topic: co-routines
Topic: concurrency
Topic: concurrency control by sequencers
Topic: concurrent operations
Topic: critical regions
Topic: deadlocks
Topic: managing shared memory
Topic: message queues for communication
Topic: models of parallel computation
Topic: monitored statements and events
Topic: parallel control statements
Topic: parallel programming languages
Topic: race conditions
Topic: safe use of pointers
Topic: synchronized processing
Topic: updating information with locking
Topic: waitfor condition in parallel processing
| |
Subtopic: monitor
Quote: a monitor is a scheduler for a resource with associated data and procedures; serves only one program at a time; organizes the critical regions [»hoarCA10_1974]
| Quote: a monitor manages a resource with mutual-exclusion; users simply execute allocate and release procedures [»dennPJ_1980]
| Quote: a monitor consists of shared data, a mutex, and zero or more condition variables [»birrAD_1991]
| Quote: a mutex protects the invariant of the associated data; restore the invariant before calling Wait or Signal [»birrAD_1991]
| Quote: implement critical regions by a shared class or monitor; its operations exclude each other over time [»brinP_1973]
| Quote: combine critical regions into a secretary process; invoked, as needed, by its directors; order is undefined [»dijkEW2_1971]
| Subtopic: condition variable vs monitor
Quote: Modula-3's condition variables are simpler than Hoare's original design for monitors
| Subtopic: messages vs monitor
Quote: message-passing is the major alternative to monitors [»bacoDF10_2000]
| Quote: parallel processes usually don't care what happens to results; an asynchronous 'out' statement is better than a monitor call [»carrN4_1989]
| Subtopic: timestamp vs monitor
Quote: V uses time servers to serialize access to resources; better than monitors since independent of client [»cherDR4_1984]
| Subtopic: synchronization within monitor
Quote: use wait and signal operations inside a monitor to wait for other resources [»hoarCA10_1974]
| Quote: synchronize through monitors with explicit await queues; insures mutual exclusion of access to monitored variables [»brinP4_1999]
| Subtopic: fine-grained locking
Quote: since a monitor locks an entire data structure, PORTAL has resources to lock individual data items; i.e., semaphores [»schiR4_1980]
| Quote: for write-once fields, the commit/reconcile/fence (CRF) memory model needs monitor-like locks and a freeze op
| Subtopic: priority scheduling for monitors
Quote: deadline promotion -- a task with a short deadline can promote a task with a long deadline if it holds a locked monitor [»clarDD12_1995]
| Quote: in PORTAL, a priority is assigned to both processes and monitors; if a process inside a monitor, it takes the monitor's priority [»schiR4_1980]
| Subtopic: implementation of monitors
Quote: Guava avoids lock fields in object headers; only monitors require locks [»bacoDF10_2000]
| Quote: Guava monitors are always synchronized; other instances are uniquely owned by a single monitor and never need synchronizing [»bacoDF10_2000]
| Quote: Guava implements monitors with concurrent readers and exchange of richer data types; guarantees no data races [»bacoDF10_2000]
| Quote: each process is on exactly one process queue; used for monitor locks, condition variables, and fault handlers [»johnRK3_1982]
| Quote: lightweight monitor using a 32-bit lock in each object; hash tables for other data; 21x faster w/o contention, 7x faster w/ contention [»yangBS3_2005]
| Subtopic: problems with monitors
Quote: when writing mutex code must manage locks, decide on lock granularity, and handle deadlock; hides important safety and progress properties [»harrT10_2003]
| Quote: implementations of monitors typically do not guarantee mutual exclusion; too restrictive [»bacoDF10_2000]
| Quote: for short reads, simple mutex often better than a reader-writer lock [»smaaB2_2006]
|
Related Topics
Topic: asynchronous processing (30 items)
Topic: co-routines (13 items)
Topic: concurrency (33 items)
Topic: concurrency control by sequencers (27 items)
Topic: concurrent operations (22 items)
Topic: critical regions (58 items)
Topic: deadlocks (21 items)
Topic: managing shared memory (74 items)
Topic: message queues for communication (36 items)
Topic: models of parallel computation (33 items)
Topic: monitored statements and events (16 items)
Topic: parallel control statements (12 items)
Topic: parallel programming languages (14 items)
Topic: race conditions (33 items)
Topic: safe use of pointers (102 items)
Topic: synchronized processing (35 items)
Topic: updating information with locking (20 items)
Topic: waitfor condition in parallel processing (20 items)
|