из других минусов - overhead на создание ссылок и непредсказуемое время работы деалокации ссылки

а ещё непредсказуемая глубина рекурсии

стека

а ещё непредсказуемая глубина рекурсии

++

Может есть в бусте что-то похожее?

я когда-то тоже гуглил. раз ты ночь гуглил, то наверное знаешь даже больше, чем я. вот эту еще находил, она вроде не такая мертвая https://github.com/ytakano/radix_tree

https://medium.com/@phostershop/building-a-c-hybrid-spin-mutex-f98de535b4ac#.6lf3aanpb

https://medium.com/@phostershop/building-a-c-hybrid-spin-mutex-f98de535b4ac#.6lf3aanpb

преамбула агонь!) да и статья доставляет. мне вообще многопточные штуки нравятся всякие

а вот тут рекомендую про локфри, атомики и скорость! http://moodycamel.com/blog/2014/detailed-design-of-a-lock-free-queue

а вот тут рекомендую про локфри, атомики и скорость! http://moodycamel.com/blog/2014/detailed-design-of-a-lock-free-queue

? #lockfree #concurrency

? #lockfree #concurrency

Вот это серия хороша кстати https://habrahabr.ru/post/314948/

Личное мое имхо. Чем возиться с этими lock free структурами данных проще разобраться как реализовывать кооперативную многозадачность на плюсах и делать количество потоков равное количество ядер, и каждое независимо от другого. А внутри потоков все раскинуто по эвентам.

А так эти лок фрии структуры поощеряют потоковый ад внутри приложения

https://twitter.com/HookTM/status/807622367144865793

А так эти лок фрии структуры поощеряют потоковый ад внутри приложения

А как ты между потоками будешь данные гонять?

Когда тебе надо чертовски быстро

Ну во первых не нужно данные между потоками гонять

А вообще мне атомики полюбились, особенно если билдить интеловским компилем - на xeon'ах в 2-3 раза быстрее

Ну во первых не нужно данные между потоками гонять

У всех разные горшочки

а во вторых не встречал я такие задачи, в которых обычные мьютексы не прокатят

а во вторых не встречал я такие задачи, в которых обычные мьютексы не прокатят

Они всегда прокатывают

Но если задача выжать максимум из железа

Например разбирать 10ge на лету :D

а во вторых не встречал я такие задачи, в которых обычные мьютексы не прокатят

Но в любом случае со своим уставом в чужой монастырь не буду лезть. Мне локфри доставляет и что самое главное решает проблемы

Я поделился тем, что считаю достойным

А статья там реально годная

Хорошо, допустим что тебе нужна максимальная производительность. Во первых, если количество потоков больше количества ядер - ты быдешь тратить дополнительное время на переключение процесса. Во вторых, у ядер процессора нет доступа напрямую ко всей оперативной памяти, есть только свой участок, или его вообще нет, и тогда он обращается к памяти через соседнее ядро.

а во вторых не встречал я такие задачи, в которых обычные мьютексы не прокатят

мьютексы да, но они обычно много переключений контекста требуют. Поэтому придумывают fast mutexes, lock-free data types и прочую ересь)

И хорошо если требуемая память будет в прямом доступе у соседнего ядра, а не у еще соседнего

была у меня схожая задача. Нормальная буферизация по писателям + мьютексы победили решение с локфри

Хорошо, допустим что тебе нужна максимальная производительность. Во первых, если количество потоков больше количества ядер - ты быдешь тратить дополнительное время на переключение процесса. Во вторых, у ядер процессора нет доступа напрямую ко всей оперативной памяти, есть только свой участок, или его вообще нет, и тогда он обращается к памяти через соседнее ядро.

о. второе - это же нума

Хорошо, допустим что тебе нужна максимальная производительность. Во первых, если количество потоков больше количества ядер - ты быдешь тратить дополнительное время на переключение процесса. Во вторых, у ядер процессора нет доступа напрямую ко всей оперативной памяти, есть только свой участок, или его вообще нет, и тогда он обращается к памяти через соседнее ядро.

Это все пройдено было. У меня есть имплементация, которая жарит нормально и всех устраивает

о. второе - это же нума

Так и что? Я к тому, что если ты шаришь данные между потоками, эти данные все равно будут находить я определенном доступе ядра. А если ты создашь несколько потоков на одном ядре, будешь терять время на переключение контекста

дак я не спорю)

Это все пройдено было. У меня есть имплементация, которая жарит нормально и всех устраивает

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

в то время как кооперативная многозадочность эти проблемы не создает

можно совместить N тредов на N ядер и локфри

Но в любом случае со своим уставом в чужой монастырь не буду лезть. Мне локфри доставляет и что самое главное решает проблемы

Я и не лезу, это мое имхо

достойный компромисс)

можно совместить N тредов на N ядер и локфри

Ну я же уже сказал, если у тебя будет количество потоков больше чем количество ядер, будешь терять на переключение контекста

Речь шла о максимальной производительности

можно совместить N тредов на N ядер и локфри

Потоки только на нечётных ядрах запускаю :)

Ибо hyperthreading

так вот она доступна только при количестве ядер равное количеству потоков и отсутсвия общих данных между потоками

Ну я же уже сказал, если у тебя будет количество потоков больше чем количество ядер, будешь терять на переключение контекста

так стоп.. а кто сказал, что если у тебя 16 потокв и 16 ядер, то тебе достанется каждому потоку по ядру

так стоп.. а кто сказал, что если у тебя 16 потокв и 16 ядер, то тебе достанется каждому потоку по ядру

Это можно заставить

так стоп.. а кто сказал, что если у тебя 16 потокв и 16 ядер, то тебе достанется каждому потоку по ядру

Это биндится

Определенный поток определенному ядру

Это биндится

биндятся процессы

и потоки

Affinity*

по крайней мере через апи системы точно

как там в современном с++ не знаю

по крайней мере через апи системы точно

ты в любом случае такие вещи будешь делать через апи системы

ты в любом случае такие вещи будешь делать через апи системы

И что?

И что?

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

чот не понял мысль

я не собираюсь ничего шедулить

ERROR: S client not available

я не собираюсь ничего шедулить

ясно. ну ок)

была у меня схожая задача. Нормальная буферизация по писателям + мьютексы победили решение с локфри

Расскажи подробнее?

Там продюсер-консюмер было?

Малтипл-малтипл

А, это сложно конечно

У нас все весьма хитро. Как правило, один пишущий и много читающих

И много грязных хаков...

Например минимум аллокейтов)

зачем вам вообще аллокейты

Циклические буферы и тп

у нас был циклический буфер в разделяемой памяти, побитый на чанки

зачем вам вообще аллокейты

бывает такое что память иногда нужно выделять :)

у нас был циклический буфер в разделяемой памяти, побитый на чанки

Во-во

Мне кажется все кто через это проходит - в итоге рожают примерно похожие решения

Кто нибудь в курсе, когда закрываешь окно консоли в венде, какой то сигнал посылается?

Кто нибудь в курсе, когда закрываешь окно консоли в венде, какой то сигнал посылается?

sigint

Но по-хорошему в винде лучше на это не расчитывать.

ну я сигинт обрабатываю и логика не срабатывает

когда закрываю окно

я тут нарыл еще CTRL_CLOSE_EVENT

нужно выставлять в SetConsoleCtrlHandler

Да, вот это уже на правду похоже.

Ну я так и выставляю и логика не отрабатывает все равно

похоже и правда нельзя рассчитывать

Ну я так и выставляю и логика не отрабатывает все равно

и как выставляешь?

Обработчик указываю в SetConsoleCtrlHandler

и в нем проверяю на соотвествие сигналу, в том числе CTRL_CLOSE_EVENT

Обработчик указываю в SetConsoleCtrlHandler

/msglink