LINUX.ORG.RU

Как ускорить работу с потоками?


0

0

Всем добрый день.

Я занимаюсь созданием на Kylix 2 Ent. кроссплатформенного ПО для VRG. Все создаваемое ПО должно быть многопоточным и работать асинхронно. Пришлось создать класс обеспечивающий потокобезопасное разруливание блокировок для чтения и записи, причем читать из любого расшаренного ресурса может одновременно множество потоков, а записывать, только один, и то, только поле того, как завершаться все читающие потоки, этакий аналог TMultiReadExclusiveWriteSynchronizer, но с поддержкой вложенных блокировок(может вкладываться несколько блокировока на чение и только одна на запись). Наткнулся на следующую проблему: В виндах скорость работы потоков в 1000 раз (да именно 10^3 раз) быстрее чем в линуксе. Вопрос: «Почему так и как это побороть?»

Дистрибутив: ALT Linux Master 2.0 (листемные либы не апдейтил) – ядро 2.4.18 (по умолчанию) Kylix 2 Enterprise установлен в папку обычного пользователя (не под рутом, поэтому либы не подменял)

Извините, если мой вопрос offtopic, но хотя бы подскажите где искать.

С уважением, Сергей

anonymous

Ответ на: комментарий от anonymous

>>VRG - это отсюда: http://www.vrg.ru/ ?

Да.

>>Вам же уже намЯкивали, что с платформой разработки вы ошиблись: >>http://raleigh.ru/XML/forum/discussion.php?article=b8aud0$14c0$1@ddt.dem os.su&am p;mode=tree >>

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

Delphi/Kylix вызывает соответствующие системные функции управления мьютексами, а не реализует их самостоятельно, поэтому проблему нужно искать в одной из системных библиотек Linux'a (скорее всего libc), точнее сейчас сказать не могу, т.к. в данный момент занят отладкой в виндах.

anonymous (*) (30.08.2004 18:13:23)

anonymous
()
Ответ на: комментарий от anonymous

> Delphi/Kylix вызывает соответствующие системные функции управления мьютексами, а не реализует их самостоятельно,

Вы это точно знаете, или это догадка. Я бы не стал утверждать это так категорично. Когда я использовал борландовские инструменты при разработке (это было давно) я заметил их (борланда) тягу к изобретениям "велосипедов".

К вопросу о конструктивности, как именно Вы сравнивали производительность нитей под разными платформами. Три порядка это очень много.

anonymous
()
Ответ на: комментарий от anonymous

>> Вы это точно знаете, или это догадка. Я бы не стал утверждать это >> так категорично. Когда я использовал борландовские инструменты при >> разработке (это было давно) я заметил их (борланда) тягу к >> изобретениям "велосипедов". >>

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

Если укажете мейл, я скину вам тестовый пример на котором вы сможете увидеть это воочию, может какие идеи появятся. Что скажете?

anonymous
()
Ответ на: комментарий от anonymous

> Если укажете мейл, я скину вам тестовый пример на котором вы сможете увидеть это воочию, может какие идеи появятся. Что скажете?

Рад бы, да кайла у меня нет. Я выкачива его во второй версии, да на RH 6.2 он у меня не встал, однако помню присутствие там вайновских либ, может он с ними и линкует.

А что касается соображений, посудите сами, есть apache второй, есть MySQL, и то и другое использует нити, причем число платформ на которых они работают больше чем две, нигде нет таких расхождений в производительности, тем более, между линуксом и виндой. Вопрос - почему? И какая роль у kylix в этих проектах?

anonymous
()
Ответ на: комментарий от anonymous

Спасибо, я уже сам нашел причину проблемы. Я использовал в основе своего класса для разруливания блокировок кроссплатформенную версию TMultiReadExclusiveWriteSynchronizer, которая по-разному работает в виндах и линухах. В виндах BeginRead, работает так, как следует из его названия, а в линухах, реализации BeginRead и BeginWrite одинаковы и используют _phtread_mutex, отсюда и разность в поведении. После того, как я это учел, все заработало нормально и с нормальной скоростью, так что это была моя ошибка, а не борландовцев.

Интересная особенность, что при попытке создания 1015 потоков в линуксе, выдается exception, при том, что в винде и 8000 потоков нормально отрабатывали, хотя и медленно. Что вы на это скажете?

>А что касается соображений, посудите сами, есть apache второй, есть >MySQL, и то и другое использует нити, причем число платформ на >которых они работают больше чем две, нигде нет таких расхождений в производительности, тем более, между линуксом и виндой. Вопрос - >почему? И какая роль у kylix в этих проектах? >

Для работы с потоками Delphi вызывает функции Win32 API, а Kylix - функции из библиотеки Libc (я смотрел борландовые исходники).

anonymous
()
Ответ на: комментарий от drF_ckoff

Нашел

См. http://sources.redhat.com/ml/libc-alpha/2001-12/msg00112.html

Конечно, для реальной работы вряд ли потребуется и 300 потоков, а в юнит-тестах я устанавливаю максимальное число потоков, когда хочу проверить не только потокобезопасность (для которой больше чем достаточно и 10 потоков) но и качество их разруливания (в принципе, 1000 потоков достаточно чтобы это понять).

А задался я этим вопросом, т.к. мне показалось странным, что винды легко держат и 8000 потоков, а у линукса их 1024, причем доступны 1021, а с учетом запущенных программ и получается, что реально можно использовать 1000-1012.

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.