You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Classic modes (CS\SC) every attachment have its own private cache of allocation table contents.
Access to allocation table is protected by common allocation table lock (alloc lock).
Currently, when attachment needs to look for a page number at allocation table, it acquires alloc lock in SH mode.
But it is not necessary if corresponding part of allocation table is already cached by attachement as allocation
table entries is never changed, it is only appended.
More, a lot of unnecessary requests for a SH lock not allows writers to proceed as quick as it can.
The improvement is to introduce additional local (per-attachment) read-write lock to protect access to the
attachment's private cache of the allocation table. It allows to significantly lower contention on global lock.
Submitted by: @hvlad
In Classic modes (CS\SC) every attachment have its own private cache of allocation table contents.
Access to allocation table is protected by common allocation table lock (alloc lock).
Currently, when attachment needs to look for a page number at allocation table, it acquires alloc lock in SH mode.
But it is not necessary if corresponding part of allocation table is already cached by attachement as allocation
table entries is never changed, it is only appended.
More, a lot of unnecessary requests for a SH lock not allows writers to proceed as quick as it can.
The improvement is to introduce additional local (per-attachment) read-write lock to protect access to the
attachment's private cache of the allocation table. It allows to significantly lower contention on global lock.
Commits: 6a80667 87ee6b8 FirebirdSQL/fbt-repository@cff9a16 FirebirdSQL/fbt-repository@eefc95a
The text was updated successfully, but these errors were encountered: