Topic: concurrency control by monitors

topics > computer science > Group: parallel processing

asynchronous processing
concurrency control by sequencers
concurrent operations
critical regions
managing shared memory
message queues for communication
models of parallel computation
monitored statements and events
parallel control statements
parallel programming languages
race conditions
safe use of pointers
synchronized processing
updating information with locking
waitfor condition in parallel processing
Subtopic: monitor up

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 up

Quote: Modula-3's condition variables are simpler than Hoare's original design for monitors

Subtopic: messages vs monitor up

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 up

Quote: V uses time servers to serialize access to resources; better than monitors since independent of client [»cherDR4_1984]

Subtopic: synchronization within monitor up

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 up

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 up

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 up

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 up

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

Related Topics up

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)

Updated barberCB 5/05
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.