http://forum.vingrad.ru/forum/topic-60076/view-all.html

Спасибо. Читаю. Начало угнетающее 

Вот только откуда старый элемент Д взялся? Надо рассматривать с самого начала:
1. очередь пуста
2. в очередь добавлен элемент А
3. в очередь добавлен элемент Б
4. из очереди извлечен элемент А и добавлен В
5. из очереди извлечен элемент Б
...

Элемент А встал в очередь первым. И первым же ее покинул.

Да именно так и есть  все правильно 

Ребят, допустимо ли такое использование критической секции?

Не будет ли трудностей если два потока одновременно вызовут одну функцию одного объекта, при условии что внутри функции автоматически используется критическая секция?

Это сообщение отредактировал(а) NYX - 29.7.2012, 21:46

NYX, собственно именно для этого критические секции и существуют.
Рекомендую тебе использовать RAII для организации критических секций:Эта технология используется во всех современных библиотеках С++. В частности, в стандарте C++11: std::mutex и std::lock_guard.

Простите, если я не правильно понял схему желаемого сервера, но я бы сделал так:
Создал класс в  котором прикрепил 1  - "map" - для базы клиентов,  2 - сокетный протокол (сервер, клиент), 3 - сохранения баз данных.
Затем это все размножил бы класс по количеству групп, - дав каждой группе свой порт ожидания.
В итоге получиться независимые группы со своими серверами и базами данных без необходимости синхронизаций... 

Добавлю:
Тоже самое можно создать и на одном ожидающем порту, только потом разбрасывать каждому классу отдельно его клиента, но тут уже надо будет одну синхронизужку  делать..


Это сообщение отредактировал(а) SVN74 - 29.7.2012, 22:22

Можно было бы вообще группы клиентов разбить на процессы отдельные. Но, допустим челу надо скаконуть из одноу группы, чонить написать и смотаться в другую.... группы динамические и основной акцент на скорость их формирования. Можно было бы выделять например 2-4 пустые группы, в случае чего юзвери туда могли бы прошмыгнуть создав новую. Переход в уже готовую группу (где есть участники, не темперную) производился бы просто под средством присваивания пары указателей  то есть, имеется всего изначально, дву группы:
А) нераспределенные пользователи (общий чат)
Б) группа (конференция)

Группа А всего одна и из нее юзвери переводятся в любую из множества групп Б. Сам переход обуславливается присваиванию указателей на ЧАСТЬ очереди, которую надо обработать в потоках группы. То есть переход, есть не что иное как "ткнуть поток носом в миску, откуда лакать.". Если речь идет о новой группе... она как бы и есть но ее как бы и нет. То есть, создание группы условно говоря это когда боле 1го собеседника находятся в общей комнате. Сама общая комната разумеется делается по запросу. Запрос выглядит примерно так "отцепи меня от нераспределенной группы и сделай отдельной группой вон с тем чуваком". Создается новых трипотока куда заведомо посылаются указатели на область очереди 2х собеседников. Очередь есть не что иное как глобальный массив стеков. Он есть до тех пор, пока есть пользователь. То есть основная нагрузка падает только на создание потоков обслуживания:
* вход. трафик
* калькуляция
* выход. трафик
Но блин я хз как масштабируемость делать. Как можно с такой схемой распределить нагрузку. Пока что на заметке у меня memory-maped file, но я еще не знаю можно ли использовать удаленно их и вообще выгодно ли это. Если это не выгодно, то кирдык-бабай. Если авалибл, то тогда шаровый мемори-мэпед файл, деление сервера на 2 составляющих
1) обработка i\o очередей (стеков)
2) калькуляция ->
3) база данных (ну это еще хз нужна ли она для чата, но пусть будем считать что нужна для хранения последних нцати сообщений, что бы вновь прибывшие смогли прочитать их при джоинте)

каждый из пунктов является отдельным VPS (наверно на физическом уровне).

Блин а еще вот я так думаю, сколько еще ждать до момент MinGW в стандарте С++11  у меня уже слюни текут при зачтении новых возможностей STL! Читаю и плачу томными ночами в ожидании нового компилятора.

Это сообщение отредактировал(а) NYX - 29.7.2012, 22:38

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

По моему мнению, - группы на то и группы, чтобы не контактировать...


Это сообщение отредактировал(а) SVN74 - 29.7.2012, 22:48

Про RAII - я мальца сократил код. Ваще где то подглядел обертку для критсекций, там в конструкторе делается инициализация, в дуструкторе соответственно...  публики лок, трайлок, анлок. В реальном счас исходнике у меня эта обертка трудится. Создается некий объект, пусть это будет отображение чего-то там где то в консольке и к этому объекту имеется доступ с двухнцати потоков. И внутри потока уже нет необходимости делать эти постоянные вызовы. В пространстве объекта уже есть обертка которая используется во всех потенциально-потокововызываемых функциях. Но меня немного смутило (Опять таки я дуб в низкоуровневом, постепенно вникаю по мере возможности, но отдельно изучению отладке время не уделяю) то что функция объекта одна и вызов функции двойной, а вот тело функции уже лок-анлок. (очень коротко сказал). просто в случае критсекций в потоке, получается как, не выполняется тело потока (потоки ведь разные экземпляры функций и тел или один и тот же тел?) и именно тело лочится. А в случае функции объекта, это уже ... одна и та же получается. Я только в этом усомнился. В целом, если я предполагаю что использовать такие возможности допустимо, то наверно я вкурил в эту тему  Что то еще блин сказать хотел...

Добавлено @ 22:49
Клиента размножать?... ну ваще длительность потоков она наверно более высока нежели длительность многоликости клиента. Хотя... Я ваще не хочу создавать много потоков. Блин это отстой. Но я пока не подкован в потоках и не знаю какие сложности в производительности возникнут. Я еще краем уха слышал что потоки можно привязать к N процессору. Так ли это? Реализуемо ли это на WinAPI? Я так и не понял. Буду искать.

Если размножать клиента, то тогда ваще можно использовать от силы несколько потоков, для групп и нераспределенных юзверей. Тогда все будет диктоваться объектом очереди, где уже будет указано кто есть who   и так же для двух типов пользователей используется свое перечисление пользователей, в котором могут будлироваться юзвери обоих групп.

Это сообщение отредактировал(а) NYX - 29.7.2012, 22:55

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

На одном потоке тоже было бы круто, но... мне не принципиальны потоки. Я так опнимаю самое главное это масштабируемость сервера и грамотное распределение нагрузки и лучше ваще автоматизированное. Если это возможно на одном потоке? Хм, быть одному потоку. Просто если потоков много, и юзвери допустим молчат, поток замораживается. В этом и прелесть. А однопоточное ПО оно будет безконца парсить очереди на предмет наличия. Либо так же создавать флаги наличия позиций очереди...

Это сообщение отредактировал(а) NYX - 29.7.2012, 22:58

А сколько будет предположительное количество  клиентов одновременно работать?

Пальцем в небо - тысяща кляентоф :] но опять же, что делать с наплывом зомбочатеров? Вдруг народу захочется поболтать, куда их посылать? Мимо или на размножаемые серверы с логин-сервера? или как васче делать то? Если бы я знал как организовать шаровые ресурсы между двумя физическими серверами при условие что шаровые данные будут под треды и разделяемыми... знать-бы вот...

  
Та Вы что ? 
Забудьте о многопотоковости, это для Вас убийство, только неблокирующий сокет и общая база...
Максимум 200 клиентов можно гонять по потокам, а если выше, только через один неблокирующий поток...

Это сообщение отредактировал(а) SVN74 - 29.7.2012, 23:10