Здравствуйте, пффф, Вы писали:
Pzz>>Ну молодец. А знал бы, как это правильно называется, воспользовался бы готовым.
П>А готового spin lock'а у вас там не было, потому и писал своё
Spin lock хорош в ядре, где его захват попутно блокирует скедулер, и, тем самым, обеспечивает синхронизацию между ядрами процессора.
В user space толку от него заметно меньше. Если его кто-то держит, кому в данный момент процессора не хватило, а кто-то другой его хочет, так и будет крутиться, как угорелый, пока текущему владельцу опять не дадут поработать.
Да, я в курсе, что Microsoft считает, что при входе в критическую секцию есть смысл немного поболтаться на спинлоке в надежде, что вдруг повезет.
Здравствуйте, Pzz, Вы писали:
Pzz>>>Ну молодец. А знал бы, как это правильно называется, воспользовался бы готовым.
П>>А готового spin lock'а у вас там не было, потому и писал своё
Pzz>Spin lock хорош в ядре, где его захват попутно блокирует скедулер, и, тем самым, обеспечивает синхронизацию между ядрами процессора.
Это не отменяет того факта, что спин лока в линупсе долго не было
Pzz>В user space толку от него заметно меньше. Если его кто-то держит, кому в данный момент процессора не хватило, а кто-то другой его хочет, так и будет крутиться, как угорелый, пока текущему владельцу опять не дадут поработать.
Есть статистика? Или так, чисто побалаболить?
Спинлок здорового человека засыпает на мьютексе после некоторого количества циклов. Как угорелый крутится только спин лок курильщика, и, возможно, линупсоида
Pzz>Да, я в курсе, что Microsoft считает, что при входе в критическую секцию есть смысл немного поболтаться на спинлоке в надежде, что вдруг повезет.
Если потрогать пару переменных — то несомненно, это дешевле, чем сразу в ядро нырять. А если что-то долгое — так у винды можно wait'ить почти на любом хэндле, и тут опять мьютексы не нужны. Это просто POSIX ущербный
Вот этого товарища послущай https://www.youtube.com/watch?v=NawpxG81RRk
Всего видюх по 10-20 минут — самое оно для начала параллельности в С++
Все очень просто и понятно.
И про mutex, и про lock_guard, и про unique_guard, про recursive_mutex
И про передачу параметров с возвратом результатов, и про вызов методов.
В общем — абсолютно необходимый минимум.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, пффф, Вы писали:
П>Здравствуйте, Pzz, Вы писали:
П>>>А я под виндой использовал CriticalSection, а под линупсом — сам аналог её писал, и мне как-то пофигу было, какие где мьютексы, где рекурсивные, а где — не очень
Pzz>>Ну молодец. А знал бы, как это правильно называется, воспользовался бы готовым.
П>А готового spin lock'а у вас там не было, потому и писал своё
А зачем?
В Linux mutex реализован через атомарные переменные,
то есть там несколько циклов происходит попытка "захватить" блокировку,
по сути "spin lock", а только потом поток засыпает.
По идее там все выверено по количеству итераций "spin lock" перед засыпанием,
чтобы зря циклы CPU не жечь в "busy loop" и не делать лишних системных вызовов
если lock/unlock защищают небольшой участок кода.
Здравствуйте, Zhendos, Вы писали:
Z>В Linux mutex реализован через атомарные переменные, Z>то есть там несколько циклов происходит попытка "захватить" блокировку, Z>по сути "spin lock", а только потом поток засыпает.
Ты токашо описал виндовый Critical Section.
Z>По идее там все выверено по количеству итераций "spin lock" перед засыпанием,
И оно само угадывает какой длительности код под локом чтоб проспинать ровно сколько нужно, ага!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Maniacal, Вы писали:
M>>я про стандарты. CC>Posix это не стандарт а говно мамонта.
POSIX (англ. Portable Operating System Interface — переносимый интерфейс операционных систем) — набор стандартов, описывающих интерфейсы между операционной системой и прикладной программой (системный API), библиотеку языка C и набор приложений и их интерфейсов. Стандарт создан для обеспечения совместимости различных UNIX-подобных операционных систем и переносимости прикладных программ на уровне исходного кода, но может быть использован и для не-Unix систем.
Серия стандартов POSIX была разработана комитетом 1003 IEEE. Международная организация по стандартизации (ISO) совместно c Международной электротехнической комиссией (IEC) приняла стандарт POSIX под названием ISO/IEC 9945[2]. Версии стандарта POSIX являются основой соответствующих версий стандарта Single UNIX Specification. Стандарт POSIX определяет интерфейс операционной системы, а соответствие стандарту Single UNIX Specification определяет реализацию интерфейса и позволяет операционным системам использовать торговую марку UNIX[3].
Т.е. SysV и BSD тоже не стандарты? Зачем же они тогда в линуксах поддержаны. Да, мелкомягкие их ещё 20 лет назад не признали, свой блэкджек замутили.
Здравствуйте, Maniacal, Вы писали:
M>Зачем же они тогда в линуксах поддержаны.
Это ты у пингвина спрашивай
M> Да, мелкомягкие их ещё 20 лет назад не признали, свой блэкджек замутили.
И правильно сделали, куда вменяемее получилось.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
M>> Да, мелкомягкие их ещё 20 лет назад не признали, свой блэкджек замутили. CC>И правильно сделали, куда вменяемее получилось.
Но потом всё равно пришлось притаскивать к себе UTF-8, ANSI escape sequences, симлинки и прочие достижения цивилизованного мира. Куда деваться с подводной лодки?
Хотя, наверное, asynchronous IO в NT более лучше сделан, чем в Unix. Что, собственно, неудивительно, учитывая разницу во времени между их появлением.
Здравствуйте, ?, Вы писали:
CC>>И правильно сделали, куда вменяемее получилось.
?>Но потом всё равно пришлось притаскивать к себе UTF-8
Это в каком месте то? Везде со времён NT используется UCS2
?> ANSI escape sequences
Опять таки где?
?> симлинки
Банально расширили Reparse points
?> и прочие достижения цивилизованного мира.
А именно?
?>Что, собственно, неудивительно, учитывая разницу во времени между их появлением.
В основном потому что им не надо было запихивать себя в прокрустово ложе откровенно устаревших интерфейсов.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
M>> Да, мелкомягкие их ещё 20 лет назад не признали, свой блэкджек замутили. CC>И правильно сделали, куда вменяемее получилось.
Согласен, но когда под Линух пишешь или кросс-платформенное решение, то никак не помогает. Если только собственные библиотеки (или чужие) юзать, которые в зависимости от платформы компилируют одну свою часть реализации или другую.
у Винды очень тесная интеграция GUI и API те же messages. В *nix универсальный и, потому, более тормозной GUI.
Здравствуйте, Maniacal, Вы писали:
M>Согласен, но когда под Линух пишешь или кросс-платформенное решение, то никак не помогает.
И не должно.
M>В *nix универсальный и, потому, более тормозной GUI.
Всё универсальное это мешок компромиссов, в итоге работает одинаково хреново на всём.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, пффф, Вы писали:
П>Ну и сам std::thread. Что-то не понятно, можно ли и как ему подсунуть нестатическую функцию класса. В винде и в POSIX решалось через статический переходник, адрес объекта передавался через void* параметр. Тут аналогично надо приседать или есть варианты получше?
Полистал ответы, не увидел вариантов без "переходника". Может, пропустил.
Переходник не нужен. Вот:
struct A
{
void run(int, const std::string&) { /*do stuff*/ }
};
int main()
{
A a;
std::thread t{&A::run, &a, 1, ""};
t.join();
}
Здравствуйте, пффф, Вы писали:
П>ЗЫ Тыщу лет многопоточки не писал, да и в новых плюсиках не очень ориентируюсь, звиняйте за глупые вопросы
В джаве сейчас моднявая тема — реактивность. Она предлагает отказаться от потоков в пользу неблокирующего кода, работающего на ограниченном количестве потоков (т.н. рельсах). Профит в том, что переключение контекста потоков очень дорогое, а тут переключения нет, поэтому нагрузку держит бОльшую. Но писать код реактивных стримов надо так, чтобы он был неблокирующим, иначе он залочит рельсу и застопорит конвейер рельсы.
В плюсах есть нечто подобное?
Здравствуйте, gyraboo, Вы писали:
g> В джаве сейчас моднявая тема — реактивность. Она предлагает отказаться от потоков в пользу неблокирующего кода, работающего на ограниченном количестве потоков (т.н. рельсах). Профит в том, что переключение контекста потоков очень дорогое, а тут переключения нет, поэтому нагрузку держит бОльшую. Но писать код реактивных стримов надо так, чтобы он был неблокирующим, иначе он залочит рельсу и застопорит конвейер рельсы.
Типа, кооперативную многозадачность переизобрели что-ли?
Здравствуйте, gyraboo, Вы писали:
G>Здравствуйте, пффф, Вы писали:
П>>ЗЫ Тыщу лет многопоточки не писал, да и в новых плюсиках не очень ориентируюсь, звиняйте за глупые вопросы
G>В джаве сейчас моднявая тема — реактивность. Она предлагает отказаться от потоков в пользу неблокирующего кода, работающего на ограниченном количестве потоков (т.н. рельсах). Профит в том, что переключение контекста потоков очень дорогое, а тут переключения нет, поэтому нагрузку держит бОльшую. Но писать код реактивных стримов надо так, чтобы он был неблокирующим, иначе он залочит рельсу и застопорит конвейер рельсы. G>В плюсах есть нечто подобное?
Здравствуйте, gyraboo, Вы писали: G>В джаве сейчас моднявая тема — реактивность. Она предлагает отказаться от потоков в пользу неблокирующего кода, работающего на ограниченном количестве потоков (т.н. рельсах). Профит в том, что переключение контекста потоков очень дорогое, а тут переключения нет, поэтому нагрузку держит бОльшую. Но писать код реактивных стримов надо так, чтобы он был неблокирующим, иначе он залочит рельсу и застопорит конвейер рельсы. G>В плюсах есть нечто подобное?
Так можно было и на обычном C писать (с некоторыми оговорками):
Здравствуйте, gyraboo, Вы писали:
G>Здравствуйте, Zhendos, Вы писали:
Z>>С каких пор реактивность модная? Вроде уже много Z>>кто стал отказываться из-зак "calback hell" в пользу Z>>"async".
G>И что же, всё богатство конвейерных операторов реактивных потоков тоже в топку?
А зачем все это богатство нужно если можно просто написать несколько библиотечных "async" функций
или просто "if/while"?
Здравствуйте, Zhendos, Вы писали:
G>>И что же, всё богатство конвейерных операторов реактивных потоков тоже в топку?
Z>А зачем все это богатство нужно если можно просто написать несколько библиотечных "async" функций Z>или просто "if/while"?
Ты мне глаза открыл. Можно либо написать самому, если оно реюзается, оформить в виде библиотеки, тем более что код async — он нагляднее. Спасибо.
Либо вообще под вопросом их использование, раньше без них как-то жили, и ничего.