Splash

Concurrency and Locking

Code written with no regard for concurrency must be correct. Programmer annotations may improve effifiency
Handle many small tasks across many cores

Most code is (mostly) functional. New objects are created more often than refs are rebound. Thus, optimize for reads.
Most tasks do not have conflicting operations
# of cores in machines has nowhere to go but up (dramatically!)

Tasks cannot block while holding locks. This means deadlock is impossible
lockRead(obj) and lockWrite(obj) attempt to acquire lock, and if it is not immediately available, transaction is aborted
- Restarted when all requested locks are available
No locks are released until transaction commits or aborts (resulting in a SS2PL schedule)
Multiple cores cannot have the same object lock simultaneously
Transactions can continue, but only depend on immediate (CPU) tasks

Transactions/worlds and state merging. Impact on GC