Re: [riot-devel] Notification: Hack'n'ACK @ Tue Nov 29, 2016 5pm - 10pm (RIOT Events)

[Martine Lenders]

Hi,
we are now set-up in Berlin for this month's Hack'n'ACK. If you like to
join via PlaceCam [1] feel free to do so at

*http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-
*

RIOTers with access to the PlaceCam account: remember to remove your
PlaceCam config (located at `.local/share/daviko
GmbH/PlaceCam/PlaceCam.ini` on Linux) before starting PlaceCam, if you are
logged in, so we can have an uninterrupted conference call.

Cheers,
Martine

[1] 
*https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation#videoconferencing
*

2016-11-28 16:59 GMT+01:00 Google Calendar :

> more details »
> 
> Hack'n'ACK
>
> *When*
> Tue Nov 29, 2016 5pm – 10pm Berlin
>
> *Where*
> FU Berlin; HAW Hamburg (map
> )
>
> *Calendar*
> RIOT Events
>
> *Who*
> •
> Martine Lenders - creator
>
> Invitation from Google Calendar 
>
> You are receiving this email at the account peterschme...@gmail.com
> because you are subscribed for notifications on calendar RIOT Events.
>
> To stop receiving these emails, please log in to https://www.google.com/
> calendar/ and change your notification settings for this calendar.
>
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn More
> .
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] How do ISRs work in the context of RIOT's scheduler?

[Oleg Hahm]

Hi Kaspar!

On Tue, Nov 29, 2016 at 11:59:14AM +0100, Kaspar Schleiser wrote:
> On 11/29/2016 11:14 AM, Oleg Hahm wrote:
> > Okay, re-reading the documentation again, I agree that the behavior deviates
> > from what is written. I also see, that the behavior is indeed different on
> > different architectures which is clearly a bug.
> 
> Turns out this is done similarily on all platforms...

Except MSP430, ARM7, native, and x86, you mean? ;-)

Cheers,
Oleg
-- 
printk(KERN_ERR "%s: Something Wicked happened! %4.4x.\n",...);
linux-2.6.6/drivers/net/sundance.c


signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] How do ISRs work in the context of RIOT's scheduler?

[Kaspar Schleiser]

Hi,

On 11/29/2016 11:14 AM, Oleg Hahm wrote:

Okay, re-reading the documentation again, I agree that the behavior deviates
from what is written. I also see, that the behavior is indeed different on
different architectures which is clearly a bug.


Turns out this is done similarily on all platforms...
I've PR'ed a fix in [1].

Kaspar
[1] https://github.com/RIOT-OS/RIOT/pull/6164
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] How do ISRs work in the context of RIOT's scheduler?

[Oleg Hahm]

Hi Kaspar!

On Tue, Nov 29, 2016 at 10:41:11AM +0100, Kaspar Schleiser wrote:
> On 11/29/2016 10:27 AM, Oleg Hahm wrote:
> > I would call it rather a bug in the documentation. The behavior of the
> > scheduler for threads of the same priority is simply underspecified.
> 
> We had that discussion offline. The "bug" is both in Cortex-M's ISR
> handling and in the docs.

Okay, re-reading the documentation again, I agree that the behavior deviates
from what is written. I also see, that the behavior is indeed different on
different architectures which is clearly a bug.

> > "Assigning the same priority to two or more threads is usually not a good
> > idea. A thread in RIOT may run until it yields (thread_yield) or another
> > thread with higher priority is runnable (STATUS_ON_RUNQUEUE) again. Multiple
> > threads with the same priority will therefore be scheduled cooperatively: 
> > when
> > one of them is running, all others with the same priority depend on it to
> > yield (or be interrupted by a thread with higher priority).
> 
> This last half sentence (in braces) is wrong. A higher thread might
> interrupt one with "siblings" of the same priority, but after the
> high-prio thread is done, the scheduler would switch back to the initial
> thread.

That's probably my fault. I always thought that `sched_run()` would advance
the pointer which is apparently not true.

Cheers,
Oleg
-- 
The great thing about SQL transaction jokes is that once you BEGIN, you can
ROLLBACK if nobody gets them.


signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] How do ISRs work in the context of RIOT's scheduler?

[Kaspar Schleiser]

Hi,

On 11/29/2016 10:27 AM, Oleg Hahm wrote:
> I would call it rather a bug in the documentation. The behavior of the
> scheduler for threads of the same priority is simply underspecified.

We had that discussion offline. The "bug" is both in Cortex-M's ISR
handling and in the docs.

> "Assigning the same priority to two or more threads is usually not a good
> idea. A thread in RIOT may run until it yields (thread_yield) or another
> thread with higher priority is runnable (STATUS_ON_RUNQUEUE) again. Multiple
> threads with the same priority will therefore be scheduled cooperatively: when
> one of them is running, all others with the same priority depend on it to
> yield (or be interrupted by a thread with higher priority).

This last half sentence (in braces) is wrong. A higher thread might
interrupt one with "siblings" of the same priority, but after the
high-prio thread is done, the scheduler would switch back to the initial
thread.

We should re-word the whole paragraph.

> Hence, if we change the scheduler and update the documentation accordingly, we
> should also make sure that the pointer in the list of threads with equal
> priority is not advanced if a thread gets interrupted by a thread with a
> higher priority, either. I.e., the pointer should only be advanced if a thread
> explicitly calls `thread_yield()`.

That is already the case. thread_yield() advances the current priority's
circular list, then calls thread_yield_higher().
But the ISR handling should directly call thread_yield_higher() instead
of thread_yield(), as Charles pointed out.

Kaspar



signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] How do ISRs work in the context of RIOT's scheduler?

[Oleg Hahm]

Hi Kaspar!

On Tue, Nov 29, 2016 at 08:46:58AM +0100, Kaspar Schleiser wrote:
> On 11/26/2016 12:55 AM, Charles Cross wrote:
> > Perhaps this is designed for the case where actions are taken inside the
> > ISR which signal other threads (like sending IPC messages), but I'm
> > still not clear on why it would need to reschedule the previously
> > executing thread relative to other running or pending threads of equal
> > priority.
> 
> Your analysis is correct, and you might have found a bug in the
> scheduling logic.

I would call it rather a bug in the documentation. The behavior of the
scheduler for threads of the same priority is simply underspecified. The only
thing the API says here is:

"Assigning the same priority to two or more threads is usually not a good
idea. A thread in RIOT may run until it yields (thread_yield) or another
thread with higher priority is runnable (STATUS_ON_RUNQUEUE) again. Multiple
threads with the same priority will therefore be scheduled cooperatively: when
one of them is running, all others with the same priority depend on it to
yield (or be interrupted by a thread with higher priority). This may make it
difficult to determine when which of them gets scheduled and how much CPU time
they will get. In most applications, the number of threads in application is
significantly smaller than the number of available priorities, so assigning
distinct priorities per thread should not be a problem. Only assign the same
priority to multiple threads if you know what you are doing!"
[Source: https://riot-os.org/api/group__core__thread.html]

Hence, if we change the scheduler and update the documentation accordingly, we
should also make sure that the pointer in the list of threads with equal
priority is not advanced if a thread gets interrupted by a thread with a
higher priority, either. I.e., the pointer should only be advanced if a thread
explicitly calls `thread_yield()`.

Cheers,
Oleg
-- 
What's a pirate's favorite method of remote access? - ADP


signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel