Доброго времени суток! Каким образом во FreeBSD управление можно передать другому (следующиму) потоку?

Вот скажем есть у меня бесконечный цикл:

не уверен что правильно понял вас...

вам нужно выполнение какой-то функции распределять между потоками?

если да, то так:

это простой вариант. в нем возможно создание слишком многого кол-ва потоков. за этим нужно следить самому.
суть в том, что просто создаются потоки, кол-во которых, можете задавать произвольно. шедулер ОС сам распределит их.
потоки сами будут удаляться тогда, когда вернется управление из somefunction().

правильный вариант - использовать boost::asio::io_service в связке с boost::thread_group.

Это сообщение отредактировал(а) boostcoder - 28.8.2010, 16:14

Wolf, 
sched_yield

Добавлено через 1 минуту и 25 секунд
boostcoder, 
я вообще не понимаю, зачем приводить такие примеры?

какие?

boostcoder, 
у автора даже намека нет на использование boost'а
это раз (да и вообще, в этом разделе форума советовать boost как-то не кошерно, имхо)
во-вторых, если не поняли вопрос, уточните
смысл телепатии с не имеющим отношения к сути вопроса кодом?

а это что ,что-то из ряда вон выходящее?


я и предположил, что возможно не верно понял задачу..




как минимум, никому от этого не хуже.

Это сообщение отредактировал(а) boostcoder - 28.8.2010, 23:16

boostcoder, 
Нет, это не что-то из ряда вон выходящее
просто boost это не та либа, которую в принципе можно сувать (ака предлагать) куда/где попало: есть куча всяких задач, начиная с использования только С и заканчивая специфическими окружениями, где boost не применим

Короче, считаю пример бессмысленным в плане пользы автору от него...проехали в общем

Пример номер два. С ним, я думаю, будет яснее.



В любой операционной системе данный код приведёт к 100% загрузке процессора (или ядра на котором код выполняется) (пример - прикреплённый рисунок). Мне нужно избавиться от 100% загрузки процессора. И так, что можно для этого вставить в цикл while (true) {} ?

Присоединённый файл ( Кол-во скачиваний: 7 )
 FreeBSD_8.1_2010_08_29_15_25_03.png 91,40 Kb

я же сказал, sched_yield

MAKCim, большое спасибо! Не заметил сразу.

Что-то это не помогает. В top смотрю, разница лишь в том, что с sched_yield система грузит проц под 100%, а без sched_yield, приложение. А как можно на очень короткое время переводить процесс или поток в ожидание?

Ожидание: nanosleep.
Вы что то не правильно делаете, такой цикл вообще использовать не стоит. Думаю тут надо думать другим путем, ошибка в архитектуре.

Wolf, 
это поможет если большинство процессов не ограничены вводом-выводом
в противном случае просто некому грубо говоря передать управление и оно переходит обратно к вызывающему потоку

У меня не while(true), а примерно такое в потоках, занимающихся IO сокета:



Скорее всего я не правильно понимаю работу планировщика. В общем если в цикле ваил тру есть, что считать, например i++, и процессор свободен, то вот, собственно говоря он и считает на 100% ресурса процессора. Как то так, видимо.

Wolf, man select, man epoll, man poll.

djamshud, это то тут причём? Разумеется этим мультиплексируется обработка клиентов.

Вопрос в другом. Прочтите 1 пост.

Wolf,



Загнать их в селект?

djamshud, они и так группами опрашиваются этими функциями. Но эти функции с определённой переодичностью нужно вызывать. Вызываются они в цикле потоков (грубо говоря всё, конечно).

Это сообщение отредактировал(а) Wolf - 1.9.2010, 15:44

Wolf, извините, если я что-то не понимаю, но...

Организуем сэт сокетов. Отправляем его в селект, ставим в него какой-то таймаут. Состояние одного (ли нескольких) из сокетов изменилось - получили обратно управление, обработали, запустили все заново. Или состояния сокетов изменяются так часто, что процессор загружается на все сто процентов? Тогда ничего не поделать, но этого быть, думаю, не может.

Добавлено через 57 секунд
Собственно, даже если состояние их не изменилось, управление вернется через указанный таймаут.

djamshud, Вы не понимаете, что речь не о сокетах и методах мультиплексирования.

Ну и чтобы вам было яснее. Клиентов более 2000. Потоков в зависимости от настройки от 1 до какого либо разумного предела (пул потоков). Потоки тормозить нельзя (тем же самым блокирующим режимом select). По этому таймаут 0. Что можно читать - читаем, что можно отослать - отсылаем (опять же чётко и без блокировок). Далее берём новую группу сокетов и обрабатываем. Непрерывно.

Это сообщение отредактировал(а) Wolf - 2.9.2010, 06:58

Wolf, 
ну а то, что вы хотите, это ведь тоже своего рода блокирование
если поток не занимается ничем иным кроме работы с сокетами, то действительно непонятно, зачем непрерывный опрос

Добавлено через 2 минуты и 17 секунд
ну и по архитектуре
у каждого потока должно быть свое множество сокетов, с которым он может работать неконкурентно с другими потоками

MAKCim, пока что архитектура такова, что действительно существует конкуренция. Общий список клиентов к нему обращаются потоки для получения группы сокетов. Сокеты не закреплены за какими либо потоками. И скорее всего действительно придётся переписать механизм обработки сокетов. Вы меня заставили задуматься. Мои радужные представления о текущей архитектуре могут рухнуть   

А что посоветуете? По идее должен быть нагруженный сервер с множеством клиентов. Клиенты обмениваются между собой данными и между базами сервера. Скажем сервер видео конференций + сервер какого либо контента.

какой бы не был нагруженный сервер, всегда существует лимит одновременно обрабатываемых соединений
обусловленный производительностью системы и толщиной канала
обозначим лимит через L, а число ядер/процессоров - через N
каждому ядру/процессору соответствует поток/процесс
максимальное число соединений для него L/N
итого имеем матрицу размером L*N
каждый элемент - дескриптор (указатель, структура, ...) соединения
есть один поток, постоянно вызывающий accept()
полученный сокет диспетчеризируется одному из N потоков/процессов
каждый из N потоков/процессов циклично выполняет 3 действия
1) опрос новых соединений и добавление их в select/poll/epoll/kqueue/...
2) мультиплексирование
3) обработка
в 1) нет блокировки, т. к. у каждого потока/процесса своя часть матрицы, а доступность
нового соединения определяется флагом дескриптора
чтение и установка флага могут осуществляться параллельно без лока

MAKCim, а что насчёт общих данных и обмена сообщениями между клиентов? Тут то тоже блокировка.

Wolf, 
добавить в каждый дескриптор очередь
сообщение кидаем в очередь
соответственно добавляем пункт 4) - проверка очереди на предмет новых сообщений
очередь защищается спин-локом
чтение очереди у меня всегда выглядит след. образом

list_replace_init имеет сложность O(1)

MAKCim, тут опять же возникает множество вопросов. Как поток которому нужно передать от клиента А клиенту Б сообщение узнает в каком потоке находится его клиент? Если не будет общего списка. Второй вопрос, кто удаляет клиентов из списка? Логично, что  поток, обрабатывающий клиента. Но удалив его дескриптор, может возникнуть такая ситуация, когда кто-то пытается в удалённый из памяти дескриптор (и, соответственно, его очередь) добавить сообщение.

Извеняюсь, что уже оффтопик пошёл. Можно создать или обсудить в другой теме.

Это сообщение отредактировал(а) Wolf - 3.9.2010, 14:05

просто ;)

поток, дергающий accept(), поддерживает map адресов клиентов и перед диспетчеризацией соединения одному из потоков добавляет {ip, id} в map
ip - адрес клиента
id - номер потока
соответственно, каждый из потоков, например через пайп, связан с ним
все пайпы мультиплексируются им равно как и listen-сокет

когда i-ый поток хочет получить номер потока, он пишет в пайп запрос и получает результат

в принципе эта же схема работает и для взаимодействия между потоками (вместо очередей)
но скорость может быть ниже

матрица _не удаляется_, она статична
когда, соединение закрывается, поток достает его из select/poll/epoll/kqueue..., освобождает ресурсы и устанавливает флаг FREE в дескрипторе

когда аккептор ищет свободный дескриптор для диспетчеризации, он освобождает очередь запросов (т. к. клиент уже давно мертв)

MAKCim, спасибо, теперь многие моменты прояснились  А что можно почитать по сетевой архитектуре?

Wolf, 
боюсь только практика ну и плюс примеры реальных приложений
в книгах описание подобного рода вещей я как-то не встречал
но Стивенс в любом случае не повредит ;)

MAKCim, да я вот тоже понимаю, что лучше всего было бы работать по этому направлению в организации какой нибудь, и лучше не какой нибуть. К сожалению на данный момент нет такой возможности. У нас в городе это не востребовано. Нужно переезжать