Download presentation
Presentation is loading. Please wait.
1
I, for one, Welcome our new Multicore Overlords …
Will we hand-program the cores? Yes, but not with today’s techniques Will we parallelize code automatically? 19-Jul-19
2
Why Locking Doesn’t Scale
Sadistic Homework: Independently synchronize each end of double-ended queue when possible [Michael&Scott 1996] Cannot atomically move item from one thread-safe table to another without exposing locking protocol Relies on conventions Conservative Not Robust Deadlocks Not Composable Hard to use Lost Wake-ups Make sure blocked consumers awaken when something happens Awkward conventions (SCO Unix) /* * When a locked buffer is visible to the I/O layer BH_Launder * is set. This means before unlocking we must clear BH_Launder, * mb() on alpha and then clear BH_Lock, so no reader can see * BH_Launder set on an unlocked buffer and then risk to deadlock. */ Actual comment from Linux Kernel hat tip: Bradley Kuszmaul Must lock even if conflict “never happens” (What never? No never, …Well, hardly ever!) Swapped out while holding lock …. 19-Jul-19
3
Why Transactions Totally Rule
Summer interns at Sun programmed highly-concurrent RB-Trees, Skip Lists, etc. None were harmed. Composition is trivial (see our PPoPP paper next week) Relies on conventions Conservative Not Robust Deadlocks Not Composable Hard to use Lost Wake-ups Optimistic synchronization avoids deadlocks; backoff, queueing, etc. avoid livelock & starvation Explained in our PPoPP paper, honest! Just delimit atomic blocks Conflicts detected dynamically (no actual conflict, no synchronization) Supports non-blocking synchronization (lock-free, obstruction-free, etc.) 19-Jul-19
4
Automatic Parallelization?
“Easier to apologize than to ask permission” Effective parallelization must be aggressive, not afraid to make mistakes But that requires synchronization Locks can’t cut it Maybe optimistic, non-blocking transactions can … 19-Jul-19
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.