Средства и методы разработки

Так....... Тема lightweight threads оказалась куда интереснее, чем я когда-то думал. Изначальные обсуждения: http://electronix. …ex.php?showtopic=49082 http://caxapa.ru/122898.html Вот тут http://www.sics.se …adam/pt/expansion.html есть замечатльное объяснение, как эти самые protothreads really work Если присуждать победу за извратное использование возможностей С и С препроцессора, то protothreads - безоговорочный чемпион :) Одна и основых фишек там - переход по case оператора switch внутрь while :) Но это извращение того стоит! http://eigenclass. …ring-with-protothreads приведено очень интерсеное сравнение для некоей тестовой задачи различных многопоточных реализаций. Там создается 503 потока, которые лочат друг друга и обрабатывают очень простые данные. По сути, это тест на скорость переключения контекста и работы с семафорами. implementation memory usage time (s) GCC C (Protothreads, optimum scheduling) 220KB 0.076s GCC C (Protothreads, pessimum scheduling) 220KB 18.6s GCC C (POSIX threads) 4520KB 28.7 Как Вам выигрыш по скорости 377 раз (POSIX threads)/(Protothreads, optimum scheduling)? А выигрыш по памяти 20 раз??? optimum scheduling - это когда потоки вызываются в правильно порядке, т.е. сразу после вызова они делают свою работу и разблокируют следующий поток. pessimum scheduling - это когда потоки вызываются в обратном порядке, т.е. потоки создаются, и потом с конца начинается передача управления. В коментах к статье нашлись и более интересные вещи - State Threads Library for Internet Applications http://state-threa …ceforge.net/index.html Изначально идея этой либы - дать некий вариант lightweight thread для интернет серверов. Все мы читали книжки по сетевому програмированию для Unix, где очень красиво рассказываеся о том, как правильный сервер запускает кучу потоков, и как здорово они все живут. Только вот результат типа описанного выше заставил разработчиков Apache задуматься - а как бы сделать так, чтобы сервак не сожрал всю память и все ресурсы при попытке обслужить несколько к юзеров, одновременно зашедших на сервер. В Protothreads приятным поментом является то, что не надо париться и с помощью специальных тулзов вычитывать - а хватит ли места в памяти под стек задачи? Понятно, что тема lightweight thread тесно связана с темой автоматного программирования. Все крутится вокруг некоей общей идеи. В итоге хотелось бы сказать следующее. Панацеи нет, и идеального метода программировния тоже. Маргинальные варианты - только POSIX threads или только Protothreads едва ли будут оптимальны. Не зря авторы ОС contiki http://www.sics.se …iki/about-contiki.html пошли гибридным путем - есть и то, и то. Полный отказ от потоков не модет быть вызван причиной "у нас так мало памяти". Полная ориентация только на POSIX threads (типа у нас памяти 32Мбайт - нам не жалко) тоже не всегда оправдана - скорость иногода важнее. Непрятность состоит в том, что под POSIX threads есть много наработок. Хорошие оси позволяют получить много информации о потоке, кто чего делает и т.д. В варианте Protothreads такого не будет, т.е. там можно отлаживаться, только полагаясь на логику кода (и проверяя такую логику глазками). Вот тут еще нечто есть: cooperative light-weight threads. http://ocsigen.org/docu/1.0.0/Lwt.html Ваше мнение, коллеги?