http://electronix.ru/forum/index.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.org/hiki/threadring-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-threads.sourceforge.net/index.html
Изначально идея этой либы - дать некий вариант lightweight thread для интернет серверов. Все мы читали книжки по сетевому програмированию для Unix, где очень красиво рассказываеся о том, как правильный сервер запускает кучу потоков, и как здорово они все живут. Только вот результат типа описанного выше заставил разработчиков Apache задуматься - а как бы сделать так, чтобы сервак не сожрал всю память и все ресурсы при попытке обслужить несколько к юзеров, одновременно зашедших на сервер.
В Protothreads приятным поментом является то, что не надо париться и с помощью специальных тулзов вычитывать - а хватит ли места в памяти под стек задачи?
Понятно, что тема lightweight thread тесно связана с темой автоматного программирования. Все крутится вокруг некоей общей идеи.
В итоге хотелось бы сказать следующее.
Панацеи нет, и идеального метода программировния тоже. Маргинальные варианты - только POSIX threads или только Protothreads едва ли будут оптимальны. Не зря авторы ОС contiki http://www.sics.se/contiki/about-contiki.html пошли гибридным путем - есть и то, и то.
Полный отказ от потоков не модет быть вызван причиной "у нас так мало памяти".
Полная ориентация только на POSIX threads (типа у нас памяти 32Мбайт - нам не жалко) тоже не всегда оправдана - скорость иногода важнее.
Неприятность состоит в том, что под POSIX threads есть много наработок. Хорошие оси позволяют получить много информации о потоке, кто чего делает и т.д. В варианте Protothreads такого не будет, т.е. там можно отлаживаться, только полагаясь на логику кода (и проверяя такую логику глазками).
Вот тут еще нечто есть:
cooperative light-weight threads.
http://ocsigen.org/docu/1.0.0/Lwt.html
Ваше мнение, коллеги?