NYX, код под Windows:Код под Unix:Видишь отличия? Кроме названий никаких. Поэтому, вход в критическую секцию - это захват мьютекса, выход - освобождение. И не важно, как ты это назовешь, суть не изменится. Поэтому, у тебя остается выбор из мьютексов и семафоров.

Семафоры имеет смысл использовать когда у тебя типичная схема из m производителей и n потребителей. Производители что-то делают, добавляют в очередь и сигнализируют семафором. Потребители ждут сигнала, берут из очереди и обрабатывают.

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

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

Это сообщение отредактировал(а) NYX - 20.7.2012, 19:04

Процессы - это исполняющиеся экземпляры программ. А потоки - это составные части одного процесса. Не путай понятия.

Время блокировки нужно делать минимальным. Т.е. на время выполнения простейших операций добавления/извлечения данных из очереди. Поэтому в большинстве случае проблем не будет. Если же у тебя все так сильно нагружено, то копай в сторону lockless.

Да, на счет процессов и потоков я знаю, процесс это своего рода набор потоков, где есть первичный поток и возможность создания дополнительных. По сути процесс это набор данных (оверхед). На счет нагрузки даже примерно сказать не могу  так как не лету придумал модель такую и результат наверно только по реализации будет  Очень интересно что получится  может даже эта наработка и пригодиться когда нибудь. Кстати, вот та самая очередь входящих данных... от клиента... очередь должна быть FILO, но вот в чем беда. Как лушче его реализовать, alloc-функциями или new?  пытался засечь время затраты с помощью clock() но почему то отследить разницу не удалось. Просто если делать его не FILO а FIFO то... это будет не целесообразно, так как стек будет обрастать шлаком, чт ов итоге может привести к переполнению. А в случае FILO с new это будет провацировать:
1) Удаление старого пункта задачи для пользователя и присабачивание нового
2) Если напор уж очень сильный, то просто напросто игнорировать.
Кроме того FILO не будет замедлять работу сервера в случае если в очереди имеется от 2х заданий. Так как непосредственный доступ к отдельным данным он наверно всеж допустим. Если использовать ВСЮ очередь как целое данное, то думаю ваще смысла нет FILO оно или FIFO.

А на счет приоритетов потоков... 
Sleep(0) пока не найдется нужный поток?    Жестоко наверно...

Это сообщение отредактировал(а) NYX - 21.7.2012, 02:07

Есть у меня подозрение, что ты путаешь FIFO и FILO. FILO - это стек (first in last out - первым пришел, последним уйдешь). Т.е. ты читаешь самые свежие данные, а самые старые могут лежать до скончания века. Стек нет смысла использовать в качестве очереди.

вот в том то и дело, что что это даже не стек, а фиксированная очередь, обслуживаемая несколькими потоками, для каждого отведена определенная часть очереди. Очередь фиксированная, ее размер позволяет определить степень загаженности, и если кол-во запросов от пользователя превышает очередь, следующие запросы игнорируются. На например, пользователь сломал мышку, она лаганула и 50 раз нажала кнопку ОТПРАВИТЬ  все запросы улетят на сервер  поток обработки входящих запросов отфильтрует их по времени, оставит только валидные запросы, из них может быть и 5 запросов подярдошных. Поток калькуляции начнет с обработки САМОГО СВЕЖЕГО запроса. Они как бы будут пропихиваться в очередь СНИЗУ, а поток калькуляции будет их извлекать СВЕРХУ. Я пока еще не знаю, но скорее всего такое реализовать для массива не получится. Хотя всякое может быть... я пока что не понял как можно обслужить такой массив запросов.
А кто нибудь может что-то сказать про TLS (тот что Thread Local Storage)? Что это такое ваще? 

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

Могу сказать - забудьте про них пока   
У вас задача (про потоки и обслуживание пользователей) от поста к посту видоизменяется быстрее, чем размножаются кролики   Вы уж как нибудь определитесь с конечными требованиями, а потом вам уже можно будет что нибудь и по делу посоветовать   

Это и есть FIFO (first in first out - раньше придешь, раньше уйдешь) - стандартный контейнер std::queue. Очередь (FIFO) она и есть очередь. А стек (LIFO или FILO) - это не очередь (контейнер std::stack), это хранилище данных с обратной очередностью извлечения.

вот что я имел ввиду ->

(новый) in -> ||||||||| -> out (старый)

Как бы поступает с начала и обслуживается с конца (или наоборот. Смысл один получаетсо )) Это даже скорее как конвеер. При наличии более 2х элементов, будет наименьшая дележка ресурсов потоками. Я это имел ввиду  Я уже более менее въехал как ваще потоками пользоваться, образно уже легко представляю параллельные нити с ресурсами. На практике пока что только следовал примерам но все понятно что в них делается. Просто я еще не адаптировался к мышлению потоками, но в целом понял как и что  

Это сообщение отредактировал(а) NYX - 25.7.2012, 01:37

Это есть, первым пришел, первым уйдешь. FIFO

Блин, ну вот последовательность алгоритмическая:
1) Добавили новый элемент A
2) (возможно параллельно) Извлекли старый элемент Д
  ну он новый элемент не первым уйдет!!! Первым уйдет это как в стеке. Когда положил сверху, сверху он первым и ушел. А тут запихал снизу, а забрал сверху.   

вот допустим, есть у нас цепочка тэ динамических элементов, где 0 элемент имеет указатель на следующий и предыдущий. Новым будет элемент тот, на который указывает element[0].pprev а старым будет element[9].pnext и вот пока один поток цепляет [0].pprev второй поток отцепляет [9].pnext (индексы элементов я поставил для условности чоб яснее было)  Разве это FIFO? Если сделать что один поток цепляет [0].pnext а второй поток ждет пока первый завершит цепляние, потом по завершению захочет прочесть... а тут еще новый и еще... в итоге очередь будет расти в неимоверной прогрессии... и потоки будут драться за последнее слово. А если один пихает снизу, в этот момент ему не надо тормозиться, так как второй поток оперирует совсем другим, последним элементом. при кол-ве элементов в таком "конвеере", потоки не будут друг друга вытесянять  вытеснение начнется когда кол-во элементов будет 1  тогда они уже будут может быть как то засыпать\просыпаться до момент освобождения ресурса  Я еще пока не знаю можно ли такое вот реализовать в связке с сокетами и потоками... это вдвоейне жесть. Но гепотетически думаю реально. Я не знаю на сколько сильно будет грузить проц такая очередь + контроль ее размера (если на 1го клиента будет отделено напрмиер 200 элементов очереди) + сможет ли один поток справиться с этим. Счас эксперементирую с этим 

Это сообщение отредактировал(а) NYX - 25.7.2012, 02:14

Да, это FIFO

Черт побери, я был уверен что это нечто иное. Ну да ладно, главно суть теперь ясна. А что вы можете сказать о такой методе очереди для серверного ПО, в тех условиях где нет выделеного потока для каждого клиента, а клиенты делятся по группам, которые обслуживают потоки и на один поток приходится массив клиентов? Да и ваще, может я как неопытный, не вижу каких то подвохов в таком подходе?
Получается как...
* клиент приконнектилсо, ему выделилась очередь обладающая счетчиком контролирующим кол-во элементов очереди
* если клиент попадает в некую группу, его очередь располагается в потоке ГРУППЫ
* если клиент единственный для своей группы, или является грубо говоря нераспределенным пользователем, его очередь пихается в поток для непонятных клиентов (ну грубо говоря так). Если находится еще один клиент такой же группы, его к нему туда.. к первому АБСТРАКТНОМУ клиенту в поток, и поток уже обслуживает массив из двух очередей. в цикле из двух итераций пробегается по очередям, обрабатывает сначала 1го клиента, размещает в очередь на отдачу результата, потом второго клиента... и так далее.
Это не веб сервер это ваще хз чо за сервер... ну будем считать что это пусть будет допустим чат с залами для конференции. Блин наверно такое даже больше подходит.
* В контексте одного потока, данные очереди не могут обрабатываться другими, сторонними потоками. Это будет уже нелогично, если человек из конференции А напишит в конференцию Б  Если челу из А надо написать кому то из Б, милости просим в зал Б  соответственно, изолировать данные между потоками группы А и потоками группы Б нет необходимости. Поэтому, все что надо, каждому элементу такой очереди присвоить свой CRITICAL_SECTION (или сделать частью самого элемента, что было бы правильнее) и уже в потоке его использовать. Если дошло дело до того, что один элемент обрабатывают два потока (блин ну я тут имею ввиду контекст... немного не правильно. Контекст имел ввиду трех потоков как одного целого обрабатывающего механизма одной группы)... вот пытаются обратиться два потока одной группы к ПОСЛЕДНЕМУ и единственному элементу очереди, тогда соответственно какой то один поток получит доступ.... а точнее это и будет поток чтения очереди, потому что пока счетчик == 0 элементов нет. Как только счетчик > 0 - будим поток калькуляции.

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

есть разве что идея режимности сервера. Как например:
* режим 1 - сервер выполняет все три потока для группы
* режим 2 - сервер выполняет только прием \ отдачу
* режим 3 - сервер выполняет только калькуляцию (сердце формирования очереди отдачи + допустим фильтрация мата в чате)

И если надо наростить мощность... сервер 1го режима принимает в качестве определенной команды (может даже по удаленному терминалу) нечто вроди "rembind 192.168.1.2" и это делает следующее:
* очередь опустошается
* формируется новая очередь уже на новом калькуляторном сервере
* элегантно завершаются потоки калькуляции на первом сервере
* далее все дело функционирует на двух серверах, где время калькуляции обуславливается скоростью второго физического сервера который в свою очередь так же может давать запросы на сервер с БД

Какое ваще мнение на такую модельку? Даже пусть сложно, фиг с ним я не тороплюсь никуда, это просто эксперемент для себя 

Это сообщение отредактировал(а) NYX - 25.7.2012, 02:56

NYX, ну очень сумбурно...   


По возможности переполненя имхо, вообще по-барабану какой тип очереди. (FIFO или FILO)
Все зависит от соотношения помещающих и извлекающих потоков.
Защиту от переполнения нужно вводить в любом случае.

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

По здравому смыслу, конечно, нужно использовать FIFO. т.е. обслуживание в порядке поступления, как в очереди за сосисками.

Вообще, общий совет: думайте больше о логичности, а не о быстродействии.
Ясно устроенный механизм, легче будет и оптимизировать. Но это уже потом, если будет на то необходимость.

Ну я тоже думаю что слишком уж заморочился. Просто как то диковато воспринимать факт динамической ячейки для очереди  
точнее переодического распределения памяти. А если допустим создать 10 ячеек, и оперировать как то может быть индексом (указателем элемента), может быть было бы быстрее  На счет ясности и логики это да  по мне лучше иметь большой код, но очень понятный, чем множество стремных конструктций с 280 символные строки содержащие всевозможные ухищрения языка 
А на счет переполнения, я не ставил акцент на контроль переполнения  просто наверно не так выразился. Мне кажется что описанная мною очередь будет немного прикольнее. Но все равно, все покажет только реализация с замерами времени выполнения \ быстродействия. В общем то сегодня я уже как второй день продолжаю изгаляться над кодом, даст бог, что то выйдет из этого полезного для меня  В любом случае опыт важнее прежде всего 

Это сообщение отредактировал(а) NYX - 25.7.2012, 14:17