Hello,
I consider to replace the current priority queue implementation used for thread
queues (not the scheduler ready queue) with red-black trees. Currently we use
four chains and linear operations in the corresponding priority subset. A
red-black tree root can be reduced to at most four po
The current implementation has a bounded maximum
execution time. Does the Red-Black Tree have that
guarantee?
Technically the code to unroll the loop could be
deleted. In either case, how long would interrupts
have to be disabled?
On 11/15/2013 11:00 AM, Sebastian Huber wrote:
> Hello,
>
> I con
On Fri, Nov 15, 2013 at 12:12 PM, Joel Sherrill
wrote:
> The current implementation has a bounded maximum
> execution time. Does the Red-Black Tree have that
> guarantee?
>
As I recall, the red-black tree has an upper bound of 3 rotations
during an insert/remove, and the balance is bounded by 2x (
On 11/15/2013 11:26 AM, Gedare Bloom wrote:
> On Fri, Nov 15, 2013 at 12:12 PM, Joel Sherrill
> wrote:
>> The current implementation has a bounded maximum
>> execution time. Does the Red-Black Tree have that
>> guarantee?
>>
> As I recall, the red-black tree has an upper bound of 3 rotations
> dur
On Fri, Nov 15, 2013 at 12:27 PM, Joel Sherrill
wrote:
> On 11/15/2013 11:26 AM, Gedare Bloom wrote:
>> On Fri, Nov 15, 2013 at 12:12 PM, Joel Sherrill
>> wrote:
>>> The current implementation has a bounded maximum
>>> execution time. Does the Red-Black Tree have that
>>> guarantee?
>>>
>> As I r
On 16/11/2013 4:00 am, Sebastian Huber wrote:
_Thread_queue_Enqueue_priority() which use _ISR_Flash(). Usage of
_ISR_Flash() will be highly problematic in case we introduce fine
grained locking for SMP.
Could you please explain the issue the _ISR_Flash has in a little more
detail ?
chris@hu