[Evgeny_CD 0]

Изначальные обсуждения:

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

 

Ваше мнение, коллеги?