Transcript slides
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? – Yes, but not with today’s techniques 26-Jul-16 1 Why Locking Doesn’t Scale Cannot atomically move Sadistic Homework: • Relies on conventions item from one threadIndependently Awkward conventions Make sure blocked safe table • Conservative synchronize each to endanother of (SCO Unix)locking consumers awaken when without exposing double-ended queue • Not Robust something happens protocol /* when possible • Deadlocks * When a locked buffer is visible to the I/O1996] layer BH_Launder [Michael&Scott * is set.Must This means before unlocking we must clear lock even if conflict BH_Launder, • Not Composable * mb() on alpha “never and then clear BH_Lock, so no reader can see happens” Swapped out while holding lock * BH_Launder set on an unlocked buffer and then risk to • Hard(What to use never? No never, …Well, hardly deadlock. …. ever!) */ • Lost Wake-ups Actual comment from Linux Kernel 26-Jul-16 2 hat tip: Bradley Kuszmaul Why Transactions Totally Rule • • • • • • • Composition is trivial Summer interns at Sun (see our PPoPP paper next week) Relies on conventions programmed highlyExplained in our PPoPP Optimistic concurrent RB-Trees, Conservative paper, honest! synchronization avoids etc. None Not Robust Skip Lists, deadlocks; backoff, were harmed. Just delimit atomic blocksetc. avoid Deadlocks queueing, detected dynamically livelock & starvation NotConflicts Composable (no actual conflict, no Supports non-blocking Hard to use synchronization) synchronization (lock-free, Lost Wake-ups obstruction-free, etc.) 26-Jul-16 3 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 … 26-Jul-16 4