rtel wrote on Thursday, September 08, 2011:
I need to get a better understanding of the question.
1. Some ticket entered the queue and the consumer starts over immediately, bevause he hase the higher priority.
Ok, sounds good so far. A high priority task is blocked on a queue, waiting for data. Data is posted to the queue by a low priority task, causing the higher priority task to unblock (data is in the queue), and, as it has the higher priority, preempt the task that posted to the queue. Now the high priority task is running.
2. Consumer reaches the first point of waiting
The consumer, being the higher priority task, is blocked for a fixed period. It enters the Blocked state, which allows the lower priority producer task to execute again.
3. The producer starts again and throw in another ticket, that ok
The low priority writes to the queue again, but this time there is nothing blocked on the queue as the higher priority consumer is just delaying for a fixed period (not delayed on the queue, just delaying). Therefore the low priority task should be able to write to the queue, not get preempted as the write does not unblock anything, and just continue.
This scenario of course could result in the queue becoming full - if tasks are writing to the queue but the only task that can read from the queue is blocked doing something else.
4. The consumer immediately starts at the beginnung again, not finishing the outstanding work, getting the new ticket and ….
Up to now I have understood everything, but this bit does not make sense to me, or I have misunderstood what you are saying.
What should happen is the consumer completes is delay, leaves the Blocked state, then continues with whatever the next thing in its implementation is - which might be to read from the queue again.
What you seem to be saying is that the task just starts from the beginning of its implementation again? That can only point to a system crash/reset. The most likely cause for that would be a stack overflow. Do you have stack overflow checking switched on?
This assumes you are using an official port. If not, I cannot really comment as there may be a bug in the (unofficial) port layer. All the official ports goes through fairly extensive testing that I would hope would highlight such a bug (not that anything is 100% certain of course).