Кстати что там с асинк-стд? Нафига она нужна если есть Токио?

не нужна

если 100 тасок с таким кодом и myLock = SemaphoreSlim(1) запустить одновременно, ты внезапно обнаружишь, что у тебя в пике 100 тредов дерутся за этот myLock. вот я к чему

по условиям задачи у нас 1 тред, треды не дерутся, таски - ну да, дерутся, а как ещё

так асинхронная таска работает на треде ОС из пула

как это один тред? у нас конкурентный доступ, то есть по определению несколько одновременных высилений хотят сделать myVariable += 1;

ну мы решили что у нас будет тредпул с N=1 (MAXPROCCOUNT=1)

для простоты восприятия

Ну и славно. Рантайнм раскидывает такси по тредам, но использовать данные может одна единственная активная таска, которая прошла WaitAsync.

И эта таска выполняется в одном конкретном потоке.

Давно не следил за асинхронщиной. Так что, tokio > async-std, как показало время?

Таска сделала релиз — рантайм размораживает остальные ждущие таски.

судя по всему так и вышло. Впрочем, я не удивлен

async-std неплохо так простимулировал развитие токио.

вообще-то я говорил про кейс с несколькими тредами, а не с одним. Это очевидно, если мы обсуждаем конкурентность, data race и примитивы синхронизации
а так то да, можно ноги поциенту отрубить, тогда он точно не убежит.
Но это ты сжульничал, признай

нет, я просто упростил пример что с 1 тредом у нас не будет реэнтранса и проблем

хочешь с кучей тредов - ну ок, точно так же у нас оказывается 1 тред работает, осталньые ждут задач в тредпуле, 0 тредов заморожено

100 тасок запущенны одновременно и все кроме одной ждут, пока выполнится myLock.Release();
когда в таске доходит до await myLock.WaitAsync(); я хз что именно конкретно происходит, но ничего хорошего точно.
1) либо таска останавливается, её тред уходит назад в пул, планировщик переключается на другую таску, которая получает тред из пула - чтобы тут же вернуть его назад, поскольку блокировка не снята и т.д.
2) либо просто тред, в котором работала таска, дерётся за myLock, что логичнее, а другие таски при этом получают новый тред из пула и делают то же самое
и то и то плохо, других вариантов я не вижу

я думаю в нормальной реализации лок хранит у себя очередь. и пробуждает таски по очереди с первой по 100ую

ну к этому сводится работа системного шедулера, но это же очень и очень плохо