From 32df7bf1195fd3c90a77efb1aa7311e4655c1737 Mon Sep 17 00:00:00 2001 From: Tor Brede Vekterli Date: Tue, 9 Apr 2024 15:55:58 +0000 Subject: Low-level message fetch routine must not implicitly unlock mutex Implicitly unlocking messes up higher level assumptions about when locks are held and thus cannot be safely done. Lock will be unlocked immediately after anyway, so this does not seem like a useful optimization. --- .../src/vespa/storage/persistence/filestorage/filestorhandlerimpl.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/storage/src/vespa/storage/persistence/filestorage/filestorhandlerimpl.cpp b/storage/src/vespa/storage/persistence/filestorage/filestorhandlerimpl.cpp index 6365eb1ab30..7589fb3cdb3 100644 --- a/storage/src/vespa/storage/persistence/filestorage/filestorhandlerimpl.cpp +++ b/storage/src/vespa/storage/persistence/filestorage/filestorhandlerimpl.cpp @@ -1058,6 +1058,7 @@ FileStorHandlerImpl::Stripe::fill_feed_op_batch(monitor_guard& guard, LockedMess uint32_t max_batch_size, vespalib::steady_time now) { assert(batch.size() == 1); + assert(guard.owns_lock()); BucketIdx& idx = bmi::get<2>(*_queue); auto bucket_msgs = idx.equal_range(batch.lock->getBucket()); // Process in FIFO order (_not_ priority order) until we hit the end, a non-batchable operation @@ -1136,7 +1137,6 @@ FileStorHandlerImpl::Stripe::getMessage(monitor_guard & guard, PriorityIdx & idx auto locker = std::make_unique(guard, *this, bucket, msg->getPriority(), msg->getType().getId(), msg->getMsgId(), msg->lockingRequirements()); - guard.unlock(); return {std::move(locker), std::move(msg), std::move(throttle_token)}; } else { std::shared_ptr msgReply(makeQueueTimeoutReply(*msg)); -- cgit v1.2.3