Let blocked threads have an actual fair chance to be scheduled

Just yielding the thread is insufficient to allow blocked threads to be
scheduled. Since we process buckets in chunks of 10k for "background"
iterations, a microsecond sleep should have a minimal impact in
practice.

A more thorough fix would involve redesigning how locking and signalling
is done in the bucket DB. This simple fix should however address the
blocking issues observed with the current design.

1 files changed, 9 insertions, 1 deletions

diff --git a/storage/src/vespa/storage/bucketdb/lockablemap.h b/storage/src/vespa/storage/bucketdb/lockablemap.h
index bfc35f80f44..95d9326eff0 100644
--- a/storage/src/vespa/storage/bucketdb/lockablemap.h
+++ b/storage/src/vespa/storage/bucketdb/lockablemap.h
@@ -23,6 +23,7 @@
 #include <vespa/document/bucket/bucketid.h>
 #include <vespa/storage/common/bucketoperationlogger.h>
 #include <thread>
+#include <chrono>
 
 namespace storage {
 
@@ -671,7 +672,14 @@ LockableMap<Map>::chunkedAll(Functor& functor,
 {
     key_type key{};
     while (processNextChunk(functor, key, clientId, chunkSize)) {
-        std::this_thread::yield();
+        // Rationale: delay iteration for as short a time as possible while
+        // allowing another thread blocked on the main DB mutex to acquire it
+        // in the meantime. Simply yielding the thread does not have the
+        // intended effect with the Linux scheduler.
+        // This is a pragmatic stop-gap solution; a more robust change requires
+        // the redesign of bucket DB locking and signalling semantics in the
+        // face of blocked point lookups.
+        std::this_thread::sleep_for(std::chrono::microseconds(100));
     }
 }