Map
Index
Random
Help
Topics
th

Topic: concurrency control by monitors

topics > computer science > Group: parallel processing



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 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
[»smaaB2_2006]

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.