ydb/library/cpp/yt/threading, branch CLI_2.27.0

Intermediate changes

2025-09-30T14:11:54Z

commit_hash:d932ec0ffc0aaea61db064d99b47b64653cd406e

Track RWSpinLock acquires per thread to ensure no reentrant usages are present

2025-09-30T14:02:14Z

commit_hash:daa3d76bfd4283d7cda9ffd741c8ed10457a5c84

YT-26288: Revert fork lock to writer starving spinlock

2025-09-26T10:44:08Z

`TForkAwareSpinLock` implementation takes `ForkLock_` reader, which can (and does) violate the non-reentrancy. commit_hash:6eb1092777ac21dd8303b938f855d0cd61276641

YT-18571: Refactor traced (fomerly tracked) spin locks and add unittests

2025-08-18T06:39:02Z

commit_hash:2476930524e6179b49fbf312f907bd03413cd8b8

Intermediate changes

2025-08-17T14:33:49Z

commit_hash:ca1f7319b759adc9a144adc5d01ae005c364e806

YT-24537: Prioritize writers in TReaderWriterSpinLock, rename old version to TWriterStarvingRWLock

2025-04-17T11:47:23Z

Previously, it was possible that `TReaderWriterSpinLock` wouldn't let the writer through if there's a steady flow of readers. This change addresses that by: 1. Prioritizing writers inside the spinlock by adding an additional `WriterReady` flag that writers set on arrival. This flag doesn't allow any readers to come through. 2. Adding the proper tests to verify this functionality, as well as spinlock's behaviour under forks. 3. Clarifying the documentation about spinlock guarantees 4. Adding a TLA+ model, formally specifying and verifying the guarantees of the new spinlock. 5. Renaming the old lock to `TWriterStarvingRWSpinLock`, and replacing all usages inside YT with the new version (renaming all usages outside of YT to the WriterStarving version). This is a second attempt of REVIEW: 8233768, the first one was rolled back as it lead to deadlocks in user code with reentrant reader locks: the case of `AcquireReader(thread0) -> AcquireWriter(thread1) -> AcquireReader(thread0)` is a deadlock, as `thread0` will not be able to acquire the lock (for the second time) before `thread1` frees writer lock, and `thread1` will not be able to acquire writer lock before the reader lock will be released by `thread0`, which won't happen until `thread0` acquires the lock for the second time. See/for more context and a real example of such situation. Analogous problem can happen with fibers: this is why you shouldn't allow context switches under the lock. Wondering why this ugly name `WriterStarvingRWSpinLock` appeared in your beautiful code? No worries, if you are **sure** that you don't use reentrant locks or fiber switches under the lock, you can freely replace your usage with the new `ReaderWriterSpinLock`. The replacement is drop-in. [nodiff:caesar] commit_hash:97683f854defca00cc283f5a2a10a1730b3c9174

Revert commit rXXXXXX, YT-24537: Prioritize writers in TReaderWriterSpinLock

2025-04-15T16:53:08Z

It turns out, RWSpinLock previously accidentally supported recursive AcquireReaders, and this property was broken with the change. commit_hash:f996e7b52ef8b3d37118034530a094af0efbe435

YT-24537: Prioritize writers in TReaderWriterSpinLock

2025-04-10T12:57:08Z

commit_hash:94fee5363799655628bd7e2c144a7869a9d89002

Move libyqlplugin.so to yt

2025-02-05T17:40:36Z

Приедет в ytsaurus: Приедет в `/contrib/ydb/` Проверка, что в github ydb ничего не сломается: commit_hash:73ab1b4a3245322afc9fc6e9d71424ad07106477

Typos

2025-01-16T08:39:38Z

commit_hash:afeeeea3c2cbdec0ddeed0fea5f88df9d8575f8b