klen 1 23 ноября, 2008 Опубликовано 23 ноября, 2008 · Жалоба ситуация когда один слушает очередь а много пишут это понятно и логично, например в очередь вывода сообщений в уарт пишут разные задачки сои независимые сообщения. а вот что должно происходить если две или более задачи присосутся к одной очереди? в моем тесте FreeRTOS поступает так. 1. И первая и вторая задачи бесперпятсятвенно вызывают QueueGenericReceive и блокируются. 2. Видимо обе ждут записи в очередь 3. при записи чтение выполняет та которая?? первая присосалась, а вторая навечно заблокирована. 4. есть предположение что читать будет всегда активный поток отсюда вопросы 1. Это так и должно быть? я думаю что не меее разумно былобы в случае второй задачи вернуть код ошибки о том что очередь уже кемто читается. 2. кто действительно будет слушать очередь - тот кто первый или как? 3. что будет и что должно быть если первая присосавшаяся к очереди сам себя заблокирует, будет ли другая задача читать очередь. вобщем изза этого недопониманя я долго ловил баг в своей програмке :) пока не понял что к очереди присосавшись было два желающих читать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 23 ноября, 2008 Опубликовано 23 ноября, 2008 · Жалоба ситуация... Вообще-то для подобного одна из задач может пользовать xJustPeeking, или не использовать бесконечную блокировку, или.... В общем нужно конкретно смотреть. 2. 3. Исходники посмотреть :). А вообще, если по памяти, то слушают обе, но получит с максимальным приоритетом, а забокировавшая себя навечно соответственно слушать перестанет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrewn 0 24 ноября, 2008 Опубликовано 24 ноября, 2008 · Жалоба а вот что должно происходить если две или более задачи присосутся к одной очереди? в моем тесте FreeRTOS поступает так. Возможная, но не единственная опция. Другой способ называется message multicast или message broadcast - по аналогии с широковещательным телевидением (Москва одна, а телевизоров много...) -- AN Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 24 ноября, 2008 Опубликовано 24 ноября, 2008 · Жалоба .... К чему это было? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 24 ноября, 2008 Опубликовано 24 ноября, 2008 · Жалоба спасибо, все понятно. просто хотелось убедится что правильно понимаю. сделано все гибко - мульикаст по записи и чтению - полная шара ресурса, все кто производят действия конкурируют на основе приоритетов - если очередь не пуста и не полна то операция выполняется без блокирования активизируемой планировщиком задачей. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость Maddy 24 ноября, 2008 Опубликовано 24 ноября, 2008 · Жалоба В догон - с форума FreeRtos тут It is definitely possible, and the tasks get served in priority order. If a high and low priority task are blocked on the same queue and data arrives the high priority task will get the data, if the high priority task reads the queue again without blocking in between then it will also get the next data. If the high priority task blocks or delays, then the low priority task is the only task waiting on data and will get the next data to arrive. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться