Work Hours
Everyday: 北京时间8:00 - 23:59
The University of Sydney Page 1
Software Construction and
Design 2
SOFT3202 / COMP9202
Concurrency Design
Patterns
School of Computer Science
Prof Bernhard Scholz
The University of Sydney Page 2
Agenda
– Concurrency Pattern
The University of Sydney Page 3
Concurrency Patterns
The University of Sydney Page 4
Enterprise Applications – Concurrency Patterns
– Design patterns concerned with the multi-threaded programming paradigm
including:
– Thread pool
– Read write lock
– Optimistic Lock
– Pessimistic lock
– Active Object
– Others
The University of Sydney Page 5
Thread Pool Pattern
Enterprise/Web Application Patterns
The University of Sydney Page 6
Thread Pool Pattern
– Design pattern for achieving concurrent execution in an application
– Also known as replicated works
– Executing tasks sequentially leads to poor performance
– Some tasks may take longer time than others
– Some tasks may require communicating with other components (e.g., database)
– Several of tasks need to be executed concurrently to improve performance
The University of Sydney Page 7
Thread Pool Pattern – How it Works
.
By I, Cburnett, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=2233464
The University of Sydney Page 8
Thread Pool Pattern – How it Works
– Multiple threads are maintained by a thread pool
– Threads wait for tasks to be allocated for concurrent execution
– Tasks are scheduled into a task queue or synchronized queue
– A thread picks a task from the task queue and once the execution of the task is
completed it places it in a completed task queue
The University of Sydney Page 9
Thread Pool – Performance
– Thread creation and destruction
– Expensive in terms of times and resources
– Threads that are initially created can reduce the overhead
– Thread pool size
– Number of pre-created threads reserved for executing tasks
– Should be tuned carefully to achieve best performance
- Right number reduce time and impact on resources
- Excessive number would waste memory and processing power
The University of Sydney Page 10
Thread Pool – Configuration and Performance
– Number of threads can be adapted dynamically
– E.g., A web server can add threads if it receives numerous web requests and
remove them when number of requests drop
– Performance affected by the algorithm used to create and destroy
threads
– Creating/destroying too many unnecessary threads
– Creating too many threads consumes resources
– Destroying many threads require more time later when they are needed again
– Creating small number of threads gradually may result in long waiting times
– Destroying small number of threads gradually may waste resources
The University of Sydney Page 11
Thread Pool Pattern – Implementation
– Typically implemented on a single computer
– Can be implemented to work on server farms
– Master process (thread pool) distributes tasks to work processes on different
computers
The University of Sydney Page 12
Optimistic (Offline) Lock
Enterprise Application
The University of Sydney Page 14
Optimistic (Offline) Lock Pattern
– “Prevents conflicts between concurrent business transactions by
detecting a conflict and rolling back the transaction.”
The University of Sydney Page 15
Optimistic (Offline) Lock – When to Use it
– Optimistic concurrency management depends on the chance of
conflict
– Low (unlikely): use optimistic offline lock
– High (likely): use pessimistic lock
The University of Sydney Page 16
Optimistic (Offline) Lock – How
The University of Sydney Page 17
Optimistic Lock – How it Works
– Validate when a session loaded a record, another session hasn’t altered it
– Associate a version number (increment) with each record
– When a record is loaded that number is kept by the session along with all other
session states
– Compare the session version with the current version in the record data
– If successful, commit the changes and update the version increment
– A session with an old version cannot acquire the lock
The University of Sydney Page 18
Update Optimistic Check
The University of Sydney Page 19
Optimistic Lock – Issues
– The version included in Update and Delete statements
– Scenario:
– A billing system creates charges and calculate appropriate sales tax based on
customer’s address
– A session creates the charge and then locks up the customer’s address to calculate
the tax
– Another session edits the customer’s address (during the charge generation session)
The University of Sydney Page 20
Optimistic Lock – Inconsistent Read
– Optimistic lock fails to detect an inconsistent read
– Scenario:
– The rate generated by the charge generation session might be invalid
– The conflict will be gone undetected (charge session did not edit the customer
address)
The University of Sydney Page 21
Optimistic Lock – Inconsistent Read
– Recognize that the correctness of a session depends on the value
of a certain data field
– E.g., charge session correctness depends on the customer’s address
– Add the customer address to the change set
– Alternatively, maintain a list of items to be version-checked (bit
more code but clearer implementation)
The University of Sydney Page 22
Optimistic Lock – Dynamic Query
– Inconsistent read could be more complex
– E.g., a transaction depends on the results of a dynamic query
– Save the initial results and compare them to the results of the same query
at commit time
The University of Sydney Page 23
Optimistic Concurrency Control
The University of Sydney Page 24
Optimistic Concurrency Control
The University of Sydney Page 25
Optimistic Concurrency Control
The University of Sydney Page 26
Pessimistic (Offline) Lock
Enterprise Application Pattern
The University of Sydney Page 27
Concurrency and Long Transactions
– Concurrency involves manipulating data for a business transaction that spans
multiple requests
– Transaction management systems cannot help with long transactions, so
multiple system transactions should be used
– Why not using optimistic lock pattern?
The University of Sydney Page 28
Concurrency and Long Transactions
– Concurrency involves manipulating data for a business transaction that spans
multiple requests
– Transaction management systems cannot help with long transactions, so
multiple system transactions should be used
– Why not using optimistic lock pattern?
– Several users access the same data within a business transaction, only one will
commit but the others will fail
– Other transaction processing time will be lost (conflict is only detected at the
end)
The University of Sydney Page 29
Pessimistic Lock Pattern
“Prevents conflicts between concurrent business transactions by
allowing only one business transaction at a time to access data.”
The University of Sydney Page 30
Pessimistic Lock – When to Use it
– When the chance of conflict between two concurrent business
transactions is high
– Cost of conflict is too high regardless of its likelihood
– Use when it is really required (it has high performance costs)
– Business transactions spans across multiple system transactions
The University of Sydney Page 31
Pessimistic Lock – How it Works
The University of Sydney Page 32
Pessimistic Lock – How
- Determine type of locks needed
- Build a lock manager
- Define Procedures for a business transaction to use locks
Note: determine which record types to lock if using pessimistic lock
to complement optimistic lock
The University of Sydney Page 33
Pessimistic Lock – Types of Lock
– Exclusive write Lock: a transaction acquire a lock to edit a session
– Does not allow 2 transactions to write to the same record concurrently
– Does not address reading data
– Allow much more concurrency
– Exclusive read Lock: a transaction acquire a lock to load a record
– Obtain most recent data regardless of the intention to edit data
– Restrict concurrency
– Read/Write Lock: combines both read and write locks
– Restrict concurrency by Read lock and increased concurrency by Write lock
The University of Sydney Page 34
Pessimistic Lock – Types of Lock
– Read/Write Lock: combines the benefit of both lock types:
– Read and write locks are mutually exclusive: a record can’t be write-lock if
any other transaction owns a read lock on it and vice versa
– Concurrent read locks are acceptable: several sessions can be readers once
one has been allowed as read-lock
- Increase system concurrency
- Hard to implement
The University of Sydney Page 35
Pessimistic Lock – Which Lock to Choose
– Factors to consider:
– Maximize system concurrency
– Satisfy business needs
– Minimize code complexity - Should be understood by data molders and analysts
– Avoid choosing the wrong locking type, locking everything, or locking the wrong records
The University of Sydney Page 36
Pessimistic Lock – Lock Manager
– Define your lock manager to coordinate acquiring/releasing lock
requests
– Need to maintain which transaction (session) and what is being locked
– Use only one lock table (hash or database table) - Use Singleton (GOF) for in-memory lock table
- Database-based lock manager for clustered application server
environment
– Transaction should interact only with the lock manager but never with a
lock object
The University of Sydney Page 37
Pessimistic Lock – Lock Manager
– In-memory lock table
– Serialize access to the entire lock manager
– Database lock table
– Interact via transaction-based system
– Use database serialization
– Read and Write lock serialization can be achieved by setting a unique constraint
on the column storing lockable item’s ID
– Read/write locks are more difficult - Reads the lock table and insert into it so you need to avoid inconsistent read
– Use a separate serializable system transaction for lock acquisition to improve
performance
The University of Sydney Page 38
Pessimistic Lock – Lock Manager
– Lock protocol defines how a transaction can use the lock manager including:
– What to lock?
– When to lock and release?
– How the lock should behave when a lock cannot be acquired?
The University of Sydney Page 39
Lock Manager – When to Lock
– General rule: a transaction should acquire a lock before loading
the data
– Order of lock and load is not a matter in some cases:
– E.g., Frequent read transaction
– Perform an optimistic check after you acquire the Pessimistic lock on an
item to ensure having the latest version of it
The University of Sydney Page 40
Lock Manager – What to Lock
– Lock an ID, or a primary key, of the object/record
– Obtain the lock before you load the object/record (to ensure the
object is current)
– Lock release
– When transaction is complete
– May release before transaction completion in some cases (understand what
is the lock)
The University of Sydney Page 41
Lock Manager – Lock behaviour
– Abort when a transaction cannot acquire a lock
– Should be acceptable by end users (early warning)
