 |
MySQL 9.0.0
Source Code Documentation
|
|
MySQL 9.0.0
Source Code Documentation
|
The class which handles the logic of latching of lock_sys queues themselves. More...
#include <lock0latches.h>
Classes | |
| class | Page_shards |
| class | Table_shards |
| class | Unique_sharded_rw_lock |
| A helper wrapper around Shared_rw_lock which simplifies: More... | |
Public Member Functions | |
| ~Latches ()=default | |
| For some reason clang 6.0.0 and 7.0.0 (but not 8.0.0) fail at linking stage if we completely omit the destructor declaration, or use. More... | |
| bool | owns_exclusive_global_latch () const |
| Tests if lock_sys latch is exclusively owned by the current thread. More... | |
| bool | owns_shared_global_latch () const |
| Tests if lock_sys latch is owned in shared mode by the current thread. More... | |
| bool | owns_page_shard (const page_id_t &page_id) const |
| Tests if given page shard can be safely accessed by the current thread. More... | |
| bool | owns_table_shard (const dict_table_t &table) const |
| Tests if given table shard can be safely accessed by the current thread. More... | |
Private Types | |
| using | Lock_mutex = ib_mutex_t |
| using | Padded_mutex = ut::Cacheline_padded< Lock_mutex > |
Private Attributes | |
| char | pad1 [ut::INNODB_CACHE_LINE_SIZE] = {} |
| padding to prevent other memory update hotspots from residing on the same memory cache line More... | |
| Unique_sharded_rw_lock | global_latch |
| Page_shards | page_shards |
| Table_shards | table_shards |
Static Private Attributes | |
| static constexpr size_t | SHARDS_COUNT = 512 |
| Number of page shards, and also number of table shards. More... | |
Friends | |
| class | Global_exclusive_latch_guard |
| class | Global_exclusive_try_latch |
| class | Global_shared_latch_guard |
| class | Shard_naked_latch_guard |
| class | Shard_naked_latches_guard |
| class | Unsafe_global_latch_manipulator |
| You should not use this functionality in new code. More... | |
The class which handles the logic of latching of lock_sys queues themselves.
The lock requests for table locks and record locks are stored in queues, and to allow concurrent operations on these queues, we need a mechanism to latch these queues in safe and quick fashion. In the past we had a single latch which protected access to all of them. Now, we use more granular approach. In extreme, one could imagine protecting each queue with a separate latch. To avoid having too many latch objects, and having to create and remove them on demand, we use a more conservative approach. The queues are grouped into a fixed number of shards, and each shard is protected by its own mutex.
However, there are several rare events in which we need to "stop the world" - latch all queues, to prevent any activity inside lock-sys. One way to accomplish this would be to simply latch all the shards one by one, but it turns out to be way too slow in debug runs, where such "stop the world" events are very frequent due to lock_sys validation.
To allow for efficient latching of everything, we've introduced a global_latch, which is a read-write latch. Most of the time, we operate on one or two shards, in which case it is sufficient to s-latch the global_latch and then latch shard's mutex. For the "stop the world" operations, we x-latch the global_latch, which prevents any other thread from latching any shard.
However, it turned out that on ARM architecture, the default implementation of read-write latch (rw_lock_t) is too slow because increments and decrements of the number of s-latchers is implemented as read-update-try-to-write loop, which means multiple threads try to modify the same cache line disrupting each other. Therefore, we use a sharded version of read-write latch (Sharded_rw_lock), which internally uses multiple instances of rw_lock_t, spreading the load over several cache lines. Note that this sharding is a technical internal detail of the global_latch, which for all other purposes can be treated as a single entity.
This his how this conceptually looks like:
So, for example access two queues for two records involves following steps:
All of the steps above (except 2, as we usually know the page already) are accomplished with the help of single line:
locksys::Shard_latches_guard guard{*block_a, *block_b};
And to "stop the world" one can simply x-latch the global latch by using:
locksys::Global_exclusive_latch_guard guard{};
This class does not expose too many public functions, as the intention is to rather use friend guard classes, like the Shard_latches_guard demonstrated.
|
private |
|
private |
|
default |
For some reason clang 6.0.0 and 7.0.0 (but not 8.0.0) fail at linking stage if we completely omit the destructor declaration, or use.
~Latches() = default;
This might be somehow connected to one of these: https://bugs.llvm.org/show_bug.cgi?id=28280 https://github.com/android/ndk/issues/143 https://reviews.llvm.org/D45898 So, this declaration is just to make clang 6.0.0 and 7.0.0 happy.
|
inline |
Tests if lock_sys latch is exclusively owned by the current thread.
|
inline |
Tests if given page shard can be safely accessed by the current thread.
| [in] | page_id | The space_id and page_no of the page |
|
inline |
Tests if lock_sys latch is owned in shared mode by the current thread.
|
inline |
Tests if given table shard can be safely accessed by the current thread.
| table | the table |
|
friend |
|
friend |
|
friend |
|
friend |
|
friend |
|
friend |
You should not use this functionality in new code.
Instead use Global_exclusive_latch_guard. This is intended only to be use within lock0* module, thus this class is only accessible through lock0priv.h. It is only used by lock_rec_fetch_page() as a workaround.
|
private |
|
private |
padding to prevent other memory update hotspots from residing on the same memory cache line
|
private |
|
staticconstexprprivate |
Number of page shards, and also number of table shards.
Must be a power of two
|
private |
1.9.2