Сообщение Re[7]: внутренняя реализация std::mutex? от 18.05.2018 9:02
Изменено 18.05.2018 9:08 AlexGin
Re[7]: внутренняя реализация std::mutex?
Здравствуйте, okman, Вы писали:
O>Спинлок в такой имплементации — это вообще, как по мне, плохая идея.
Если этим спинлоком защищать только условные Get/Set для некоторого (общего для потоков) значения, то идея вроде как хорошая.
Но, конечно же, при использовании его есть риск завесить приложение, если вынесли в него некие сложные действия.
O>Во-первых, постоянно теребить глобальную переменную с xchg/cmpxchg и блокировкой шины — не есть гуд
O>(bus traffic и все такое). Как минимум, тут надо применять стратегию не "test and set", а
O>"test test and set" + какую-то разгрузку в виде yield/pause/Sleep/etc.
+100500
Вот именно о разгрузке в виде ::Sleep — я и сообщал здесь выше!
O>Во-вторых, на однопроцессорной машине крутиться в спин-цикле бессмысленно, так как лок никто в
O>это время не освободит.
Да, однопроцессорных сейчас уже давно нет, но когда-то (лет 15 назад) как-то же работала многопоточка?
O>Ну и в-третьих, если между захватом и освобождением лока поток будет вытеснен, получится
O>очень некрасивая ситуация по отношению к другим потокам, которые ждут его освобождения.
Вероятность того, что поток будет вытеснен, если внутри этого лока — только один вызов гетера/сетера стремится к нулю.
O>Особенно если лок не гарантирует порядок захвата. Так легко и систему завесить, особенно если
O>такой спинлок применять где-нибудь в критических местах — драйверы, всякие системные
O>обработчики и т.д. Встречал на практике.
+100500
Да, если внутрь этого лока вносить что-то длинное, то такое бывает.
Но здесь — вся ответственность на разработчике
Каких-либо механизмов, способных разрулить проблему IMHO не существует.
O>Спинлок в такой имплементации — это вообще, как по мне, плохая идея.
Если этим спинлоком защищать только условные Get/Set для некоторого (общего для потоков) значения, то идея вроде как хорошая.
Но, конечно же, при использовании его есть риск завесить приложение, если вынесли в него некие сложные действия.
O>Во-первых, постоянно теребить глобальную переменную с xchg/cmpxchg и блокировкой шины — не есть гуд
O>(bus traffic и все такое). Как минимум, тут надо применять стратегию не "test and set", а
O>"test test and set" + какую-то разгрузку в виде yield/pause/Sleep/etc.
+100500
Вот именно о разгрузке в виде ::Sleep — я и сообщал здесь выше!
O>Во-вторых, на однопроцессорной машине крутиться в спин-цикле бессмысленно, так как лок никто в
O>это время не освободит.
Да, однопроцессорных сейчас уже давно нет, но когда-то (лет 15 назад) как-то же работала многопоточка?
O>Ну и в-третьих, если между захватом и освобождением лока поток будет вытеснен, получится
O>очень некрасивая ситуация по отношению к другим потокам, которые ждут его освобождения.
Вероятность того, что поток будет вытеснен, если внутри этого лока — только один вызов гетера/сетера стремится к нулю.
O>Особенно если лок не гарантирует порядок захвата. Так легко и систему завесить, особенно если
O>такой спинлок применять где-нибудь в критических местах — драйверы, всякие системные
O>обработчики и т.д. Встречал на практике.
+100500
Да, если внутрь этого лока вносить что-то длинное, то такое бывает.
Но здесь — вся ответственность на разработчике
Каких-либо механизмов, способных разрулить проблему IMHO не существует.
Re[7]: внутренняя реализация std::mutex?
Здравствуйте, okman, Вы писали:
O>Спинлок в такой имплементации — это вообще, как по мне, плохая идея.
Если этим спинлоком защищать только условные Get/Set для некоторого (общего для потоков) значения, то идея вроде как хорошая.
Но, конечно же, при использовании его есть риск завесить приложение, если вынесли в него некие сложные действия.
O>Во-первых, постоянно теребить глобальную переменную с xchg/cmpxchg и блокировкой шины — не есть гуд
O>(bus traffic и все такое). Как минимум, тут надо применять стратегию не "test and set", а
O>"test test and set" + какую-то разгрузку в виде yield/pause/Sleep/etc.
+100500
Вот именно о разгрузке в виде ::Sleep — я и сообщал здесь выше!
В виде Sleep или WaitingFor... ввести ожидание, чтобы передать управление диспетчеру потоков.
O>Во-вторых, на однопроцессорной машине крутиться в спин-цикле бессмысленно, так как лок никто в
O>это время не освободит.
Да, однопроцессорных сейчас уже давно нет, но когда-то (лет 15 назад) как-то же работала многопоточка?
O>Ну и в-третьих, если между захватом и освобождением лока поток будет вытеснен, получится
O>очень некрасивая ситуация по отношению к другим потокам, которые ждут его освобождения.
Вероятность того, что поток будет вытеснен, если внутри этого лока — только один вызов гетера/сетера стремится к нулю.
O>Особенно если лок не гарантирует порядок захвата. Так легко и систему завесить, особенно если
O>такой спинлок применять где-нибудь в критических местах — драйверы, всякие системные
O>обработчики и т.д. Встречал на практике.
+100500
Да, если внутрь этого лока вносить что-то длинное, то такое бывает. Я когда-то также сталкивался с этим.
Но здесь — вся ответственность на разработчике
Каких-либо механизмов, способных разрулить проблему IMHO не существует.
O>Спинлок в такой имплементации — это вообще, как по мне, плохая идея.
Если этим спинлоком защищать только условные Get/Set для некоторого (общего для потоков) значения, то идея вроде как хорошая.
Но, конечно же, при использовании его есть риск завесить приложение, если вынесли в него некие сложные действия.
O>Во-первых, постоянно теребить глобальную переменную с xchg/cmpxchg и блокировкой шины — не есть гуд
O>(bus traffic и все такое). Как минимум, тут надо применять стратегию не "test and set", а
O>"test test and set" + какую-то разгрузку в виде yield/pause/Sleep/etc.
+100500
Вот именно о разгрузке в виде ::Sleep — я и сообщал здесь выше!
В виде Sleep или WaitingFor... ввести ожидание, чтобы передать управление диспетчеру потоков.
O>Во-вторых, на однопроцессорной машине крутиться в спин-цикле бессмысленно, так как лок никто в
O>это время не освободит.
Да, однопроцессорных сейчас уже давно нет, но когда-то (лет 15 назад) как-то же работала многопоточка?
O>Ну и в-третьих, если между захватом и освобождением лока поток будет вытеснен, получится
O>очень некрасивая ситуация по отношению к другим потокам, которые ждут его освобождения.
Вероятность того, что поток будет вытеснен, если внутри этого лока — только один вызов гетера/сетера стремится к нулю.
O>Особенно если лок не гарантирует порядок захвата. Так легко и систему завесить, особенно если
O>такой спинлок применять где-нибудь в критических местах — драйверы, всякие системные
O>обработчики и т.д. Встречал на практике.
+100500
Да, если внутрь этого лока вносить что-то длинное, то такое бывает. Я когда-то также сталкивался с этим.
Но здесь — вся ответственность на разработчике
Каких-либо механизмов, способных разрулить проблему IMHO не существует.