W>>А что конкретно глупого? X>зачем рекомендовать создавать процессы?
Например затем же для чего Goggle Chrome создает по процессу на вкладку.
X>а вообще, сдается мне, ТС совершенно не понимает сабжа...
По мне так совершенно адекватный ответ. Бывают ситуации когда совершенно адекватно завернуть библиотеку не поддерживющую многопоточность в отдельный процесс.
Иногда это единственная разумная опция. Понятно что процесс имеет penalty fee в виде overhead всего и вся.
Re[6]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, c-smile, Вы писали:
CS>Например затем же для чего Goggle Chrome создает по процессу на вкладку.
оно это делает не столько для того чтоб увеличить увеличить озывчивость браузера, сколько ради надежности.
CS>По мне так совершенно адекватный ответ. Бывают ситуации когда совершенно адекватно завернуть библиотеку не поддерживющую многопоточность в отдельный процесс.
приведите пример такой ситуации, пожалуйста.
и еще, пожалуйста, приведите пример того, почему какая-то библиотека не поддерживает многопоточность, и что означает "не поддерживает многопоточность".
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[7]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, c-smile, Вы писали:
CS>>Например затем же для чего Goggle Chrome создает по процессу на вкладку. X>оно это делает не столько для того чтоб увеличить увеличить озывчивость браузера, сколько ради надежности.
так мне кажется мы тоже хотим что бы программа работала надежно и не повисала?
CS>>По мне так совершенно адекватный ответ. Бывают ситуации когда совершенно адекватно завернуть библиотеку не поддерживющую многопоточность в отдельный процесс. X>приведите пример такой ситуации, пожалуйста.
X>и что означает "не поддерживает многопоточность".
если Вы этого не знаете, зачем отвечаете в этой теме?
---
С уважением,
Сергей Мухин
Re[8]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>так мне кажется мы тоже хотим что бы программа работала надежно и не повисала?
так вы считаете, что потоки только способствуют ненадежности и подвисанию?
да, действительно, для чего эти потоки придумали? — процессы рулят! </sarcastic>
СМ>если Вы этого не знаете, зачем отвечаете в этой теме?
глупый вброс.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[2]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pzz, Вы писали:
Pzz>Если есть уверенность, что программа помирает именно внутри LibTomCrypt'а, попробуйте OpenSSL. За ним вроде не замечены никакие придури, связанные с многопоточностью.
Здравствуйте, niXman, Вы писали:
X>и еще, пожалуйста, приведите пример того, почему какая-то библиотека не поддерживает многопоточность, и что означает "не поддерживает многопоточность".
не сорьтесь!
пример могу привести я, хотя с таким в реале не сталкивался: либа может не поддерживать многопоточность, когда несколько потоков вызывают один и тот же метод либы — а внутри этого метода используются общие данные не защищенные критической секцией... вуаля — студенческий баг
Re[4]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pzz, Вы писали: Pzz>Непонятно, с чего бы. Казалось бы, если процессор загружен, то он что-то делает, и результаты этой деятельности должны быть как-то видны.
Pzz>Может, если потоки не привязаны к ядру, то измерялка загрузки глючит?
"измерялка" == таск менеджер )))
если отвязать потоки от ядер загрузка 13-15%, если привязать 95-100% (это один процесс ест столько)
Re[3]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Кодт, Вы писали:
К>Тем более, замораживание. Странно это всё. Может, программа собрана с однопоточным рантаймом? (Безумное предположение, и его стоит исключить с самого начала).
если вы о "Multi-Threaded DLL" — то в эти настройки я не лез — и они не менялись.
я грешу на корявенький рукодельный(не мной) пул потоков. -руки еще не дошли поправить
Re[5]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, squid_etc, Вы писали:
_>"измерялка" == таск менеджер ))) _>если отвязать потоки от ядер загрузка 13-15%, если привязать 95-100% (это один процесс ест столько)
Возможно, таск менеджер измеряет загрузку каждого из ядер, а потом берет максимум. Тогда если какой-то поток крутится в цикле на одном ядре, загрузка будет около 100%, а если прыгает по ядрам, то около 100%/N, где N — количество ядер. Разумеется, о реальной загрузке системы такая цифра мало чего говорит.
Re[9]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>так мне кажется мы тоже хотим что бы программа работала надежно и не повисала? X>так вы считаете, что потоки только способствуют ненадежности и подвисанию?
А что, уже отменили гонки и дедлоки?
Как-то я пропустил видимо...
Re[6]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pzz, Вы писали:
Pzz>Возможно, таск менеджер измеряет загрузку каждого из ядер, а потом берет максимум. Тогда если какой-то поток крутится в цикле на одном ядре, загрузка будет около 100%, а если прыгает по ядрам, то около 100%/N, где N — количество ядер.
Не думаю. Впрочем, проверить просто : Task manager — Perfomance и смотри на графики по ядрам.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>либа (как Вы это называете) лежит в памяти и принадлежит процессу, а не потоку. Поэтому, если нигде в ее описании не объявлено, что она thread-safe, то использовать ее в разных thread нельзя.
Интересно, а если так ?
Делаем свою static library, экспонирующую те же функции, что и исходная, только с неким префиксом в имени. Функции просто вызывают соответствующие функции исходной library
Например, в исходной library
int sum(int x, int y)
А мы делаем
int my1sum(int z, int y)
{
return sum(x,y);
}
Делаем еще одну свою static library, экспонирующую те же функции, что и исходная, только с неким другим префиксом в имени. (в ней будет my2sum)
Итого имеем две статические library, а к ним статически прилинкованы 2 копии исходной library.
Теперь делаем EXE, к нему линкуем наши обе библиотеки. В своей программе вызываем в одном потоке my1sum, а в другом my2sum.
По идее вызов mysum1 пойдет в первую копию, а mysum2 — во вторую. А мешать они друг другу не должны, так как можно считать, что это две разные библиотеки. И thread-safe не должно быть существенным, так как это разные библиотеки.
Я нигде не ошибся ?
With best regards
Pavel Dvorkin
Re[7]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pzz, Вы писали:
Pzz>Кому просто, а кому для этого венду придется ставить
Ну ТС-то несложно. У него там аж 24 ядра. Интересно было бы посмотреть на картинку Task Manager с 24 ядрами — как он там их нарисовал
Pzz>Я не могу придумать никакого другого объяснения, почему привязка вычислительного потока к ядру может так повлиять на загрузку.
Я тоже, но я сомневаюсь, в том, что это имеет место. Вообще-то игры с affinity mask обычно мало на что влияют при одном потоке. Когда-то проверял (в надежде получить именно ускорение за счет того, что сохраняется кеш при переключении) , получил 0).
With best regards
Pavel Dvorkin
Re[9]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я тоже, но я сомневаюсь, в том, что это имеет место. Вообще-то игры с affinity mask обычно мало на что влияют при одном потоке. Когда-то проверял (в надежде получить именно ускорение за счет того, что сохраняется кеш при переключении) , получил 0).
Я думаю, при умеренной нагрузке системе хватает ума не дергать считающий поток по ядрам. По крайней мере, делать это не слишком часто. А вот при большой нагрузке у нее уже может не остаться выбора.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>либа (как Вы это называете) лежит в памяти и принадлежит процессу, а не потоку. Поэтому, если нигде в ее описании не объявлено, что она thread-safe, то использовать ее в разных thread нельзя.
PD>Интересно, а если так ?
PD>Делаем свою static library, экспонирующую те же функции, что и исходная, только с неким префиксом в имени. Функции просто вызывают соответствующие функции исходной library
PD>Например, в исходной library
PD>Делаем еще одну свою static library, экспонирующую те же функции, что и исходная, только с неким другим префиксом в имени. (в ней будет my2sum)
PD>Итого имеем две статические library, а к ним статически прилинкованы 2 копии исходной library.
PD>Теперь делаем EXE, к нему линкуем наши обе библиотеки. В своей программе вызываем в одном потоке my1sum, а в другом my2sum.
PD>По идее вызов mysum1 пойдет в первую копию, а mysum2 — во вторую. А мешать они друг другу не должны, так как можно считать, что это две разные библиотеки. И thread-safe не должно быть существенным, так как это разные библиотеки.
PD>Я нигде не ошибся ?
Если в будет вызываться старая либа внутри, то от проблемы не ушли. Если будет полная копия библиотеки, то у нас только два thread! и как вызывать? Все время проверять н омер thread?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>Если в будет вызываться старая либа внутри, то от проблемы не ушли.
PD>Нет, я же говорил, статически линковать старую либу. Ее больше нет в EXE-проекте, она скрыта внутри wrapper-либы.
что такое "EXE проект" в терминах выполнимых файлов? Есть Exe и DLL где библиотека? А где бы ни была, либо одна копия, либо несколько в разных выполнимых модулях.
Соответственно ничего не поменялось.
>>Если будет полная копия библиотеки, то у нас только два thread! и как вызывать? Все время проверять н омер thread?
PD>Не обязательно. Взять в самом начале указатели на функции и в tls их.
Ну и как? там мб 1000 ф-ий и их все придется описать заново и проинициализировать указатели в tls ? Но как мы будем инициализировать указатели? т.е. не то.
PD>Я не говорю, что решение идеально. Просто прочитал твое сообщение и подумал — нельзя ли что-то придумать. Задача показалась интересной. Думал минут 10
PD>>Нет, я же говорил, статически линковать старую либу. Ее больше нет в EXE-проекте, она скрыта внутри wrapper-либы.
СМ>что такое "EXE проект" в терминах выполнимых файлов?
EXE-проект — это проект VS, в котором собирается EXE.
>Есть Exe и DLL где библиотека?
Ни о каких DLL и речи тут не было. Речь идет о статической библиотеке.
>А где бы ни была, либо одна копия, либо несколько в разных выполнимых модулях.
И модуль тут один — EXE.
СМ>Соответственно ничего не поменялось.
Подумай еще раз.
>>>Если будет полная копия библиотеки, то у нас только два thread! и как вызывать? Все время проверять н омер thread?
PD>>Не обязательно. Взять в самом начале указатели на функции и в tls их.
СМ>Ну и как? там мб 1000 ф-ий и их все придется описать заново и проинициализировать указатели в tls ? Но как мы будем инициализировать указатели? т.е. не то.
Элементарно. Создадим потоки и в самом начале функции потока проинициализируем. Как и все tls-переменные.
PD>>Я не говорю, что решение идеально. Просто прочитал твое сообщение и подумал — нельзя ли что-то придумать. Задача показалась интересной. Думал минут 10
СМ>имхо это совсем не решение.
Твое право так считать, но хотелось бы серьезных аргументов.
СМ>>что такое "EXE проект" в терминах выполнимых файлов?
PD>EXE-проект — это проект VS, в котором собирается EXE.
т.е. никакого отношение к выполнению не имеет. имеет отношение к построению. И тогда нет там либы или есть — монопенициально.
PD>Подумай еще раз.
что тут думать — трясти надо
PD>Элементарно. Создадим потоки и в самом начале функции потока проинициализируем. Как и все tls-переменные.
PD>>>Я не говорю, что решение идеально. Просто прочитал твое сообщение и подумал — нельзя ли что-то придумать. Задача показалась интересной. Думал минут 10
СМ>>имхо это совсем не решение.
PD>Твое право так считать, но хотелось бы серьезных аргументов.
может я не понимаю что предлагается, но я вижу, что код функций из библиотеки содержится один раз во всем процессе. Это так?
Если да, то какие обертки не делай, код будет выполняться один.
Допустим, что в библиотеке одна ф-я ZZZ и её нельзя вызывать из разных потоков. Какие обертки над ней делай, её придётся вызвать! Соответственно или надо синхронихировать её вызов, и тогда о multithread забываем или приехали!
Если код дублируется, то непонятен механизм дублирования (если нет исходных текстов). И все равно могут быть проблемы, но уже из-за того, что библиотеки часто не приспособлены, иметь два кода в одном адресном пространстве.
