b7a1325c3c
This patch adds a new `BLI_mutex.hh` header which adds `blender::Mutex` as alias for either `tbb::mutex` or `std::mutex` depending on whether TBB is enabled. Description copied from the patch: ``` /** * blender::Mutex should be used as the default mutex in Blender. It implements a subset of the API * of std::mutex but has overall better guaranteed properties. It can be used with RAII helpers * like std::lock_guard. However, it is not compatible with e.g. std::condition_variable. So one * still has to use std::mutex for that case. * * The mutex provided by TBB has these properties: * - It's as fast as a spin-lock in the non-contended case, i.e. when no other thread is trying to * lock the mutex at the same time. * - In the contended case, it spins a couple of times but then blocks to avoid draining system * resources by spinning for a long time. * - It's only 1 byte large, compared to e.g. 40 bytes when using the std::mutex of GCC. This makes * it more feasible to have many smaller mutexes which can improve scalability of algorithms * compared to using fewer larger mutexes. Also it just reduces "memory slop" across Blender. * - It is *not* a fair mutex, i.e. it's not guaranteed that a thread will ever be able to lock the * mutex when there are always more than one threads that try to lock it. In the majority of * cases, using a fair mutex just causes extra overhead without any benefit. std::mutex is not * guaranteed to be fair either. */ ``` The performance benchmark suggests that the impact is negilible in almost all cases. The only benchmarks that show interesting behavior are the once testing foreach zones in Geometry Nodes. These tests are explicitly testing overhead, which I still have to reduce over time. So it's not unexpected that changing the mutex has an impact there. What's interesting is that on macos the performance improves a lot while on linux it gets worse. Since that overhead should eventually be removed almost entirely, I don't really consider that blocking. Links: * Documentation of different mutex flavors in TBB: https://www.intel.com/content/www/us/en/docs/onetbb/developer-guide-api-reference/2021-12/mutex-flavors.html * Older implementation of a similar mutex by me: https://archive.blender.org/developer/differential/0016/0016711/index.html * Interesting read regarding how a mutex can be this small: https://webkit.org/blog/6161/locking-in-webkit/ Pull Request: https://projects.blender.org/blender/blender/pulls/138370
113 lines
3.3 KiB
C++
113 lines
3.3 KiB
C++
/* SPDX-FileCopyrightText: 2023 Blender Authors
|
|
*
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
|
|
|
/** \file
|
|
* \ingroup bli
|
|
*/
|
|
|
|
#pragma once
|
|
|
|
/**
|
|
* A #CacheMutex is used to protect a lazily computed cache from being computed more than once.
|
|
* Using #CacheMutex instead of a "raw mutex" to protect a cache has some benefits:
|
|
* - Avoid common pitfalls like forgetting to use task isolation or a double checked lock.
|
|
* - Cleaner and less redundant code because the same locking patterns don't have to be repeated
|
|
* everywhere.
|
|
* - One can benefit from potential future improvements to #CacheMutex of which there are a few
|
|
* mentioned below.
|
|
*
|
|
* The data protected by #CacheMutex is not part of #CacheMutex. Instead, the #CacheMutex and its
|
|
* protected data should generally be placed next to each other.
|
|
*
|
|
* Each #CacheMutex protects exactly one cache, so multiple cache mutexes have to be used when a
|
|
* class has multiple caches. That is contrary to a "custom" solution using `Mutex` where one
|
|
* mutex could protect multiple caches at the cost of higher lock contention.
|
|
*
|
|
* To make sure the cache is up to date, call `CacheMutex::ensure` and pass in the function that
|
|
* computes the cache.
|
|
*
|
|
* To tell the #CacheMutex that the cache is invalidated and to be re-evaluated upon next access
|
|
* use `CacheMutex::tag_dirty`.
|
|
*
|
|
* This example shows how one could implement a lazily computed average vertex position in an
|
|
* imaginary `Mesh` data structure:
|
|
*
|
|
* \code{.cpp}
|
|
* class Mesh {
|
|
* private:
|
|
* mutable CacheMutex average_position_cache_mutex_;
|
|
* mutable float3 average_position_cache_;
|
|
*
|
|
* public:
|
|
* const float3 &average_position() const
|
|
* {
|
|
* average_position_cache_mutex_.ensure([&]() {
|
|
* average_position_cache_ = actually_compute_average_position();
|
|
* });
|
|
* return average_position_cache_;
|
|
* }
|
|
*
|
|
* void tag_positions_changed()
|
|
* {
|
|
* average_position_cache_mutex_.tag_dirty();
|
|
* }
|
|
* };
|
|
* \endcode
|
|
*
|
|
* Possible future improvements:
|
|
* - Avoid task isolation when we know that the cache computation does not use threading.
|
|
* - Try to use a smaller mutex. The mutex does not have to be fair for this use case.
|
|
* - Try to join the cache computation instead of blocking if another thread is computing the cache
|
|
* already.
|
|
*/
|
|
|
|
#include <atomic>
|
|
|
|
#include "BLI_function_ref.hh"
|
|
#include "BLI_mutex.hh"
|
|
|
|
namespace blender {
|
|
|
|
class CacheMutex {
|
|
private:
|
|
Mutex mutex_;
|
|
std::atomic<bool> cache_valid_ = false;
|
|
|
|
public:
|
|
/**
|
|
* Make sure the cache exists and is up to date. This calls `compute_cache` once to update the
|
|
* cache (which is stored outside of this class) if it is dirty, otherwise it does nothing.
|
|
*
|
|
* This function is thread-safe under the assumption that the same parameters are passed from
|
|
* every thread.
|
|
*/
|
|
void ensure(FunctionRef<void()> compute_cache);
|
|
|
|
/**
|
|
* Reset the cache. The next time #ensure is called, it will recompute that code.
|
|
*/
|
|
void tag_dirty()
|
|
{
|
|
cache_valid_.store(false);
|
|
}
|
|
|
|
/**
|
|
* Return true if the cache currently does not exist or has been invalidated.
|
|
*/
|
|
bool is_dirty() const
|
|
{
|
|
return !this->is_cached();
|
|
}
|
|
|
|
/**
|
|
* Return true if the cache exists and is valid.
|
|
*/
|
|
bool is_cached() const
|
|
{
|
|
return cache_valid_.load(std::memory_order_relaxed);
|
|
}
|
|
};
|
|
|
|
} // namespace blender
|