micro-os-plus / web-jekyll

The complete Jekyll source for the µOS++ IIIe web site
http://micro-os-plus.github.io
2 stars 7 forks source link

paragraph correction in file basic_concepts.md in subtitle: Disable/enable interrupts #12

Closed carlosdelfino closed 8 years ago

carlosdelfino commented 8 years ago

in file basic_concepts.md (https://github.com/micro-os-plus/micro-os-plus.github.io-source/blob/9c7c14d9db312574e6b8bc281e962f8db58549cb/pages/user-manual/basic-concepts.md) in subtitle: Disable/enable interrupts

On paragraph:

When the resource is also accessed from ISRs, the usual solution to prevent an ISR to access the resource at the same time with a thread or another lower priority ISR, is to temporarily disable the interrupts while using the shared resource.

I think the correct is:

When the resource is also accessed from ISRs, the usual solution to prevent an ISR to access the resource at the same time with a thread or another lower priority Thread, is to temporarily disable the interrupts while using the shared resource.

change lower priority ISR to lower priority Thread.

ilg-ul commented 8 years ago

no, it is correct, if you want to prevent an ISR to interrupt a thread or a lower priority ISR in an bad moment, you need to brace that moment with a critical section.

carlosdelfino commented 8 years ago

Well, I thought that an interrupt low priority could not occur inside another higher priority interrupt.

ilg-ul commented 8 years ago

it obviously cannot.

how about this:

When the resource is also accessed from ISRs, the usual solution to prevent an ISR to interrupt a thread or another lower priority ISR, is to temporarily disable the interrupts while using the shared resource.

carlosdelfino commented 8 years ago

I understood through this post: https://community.arm.com/thread/4740

An ISR lower priority is delayed until the ISR higher priority ends, unless it occurs soon after ISR highest priority causing a possible locking of the highest priority ISR, since it can set the recorder in advance PRIMASK the execution of the ISR highest priority, so it will not have started yet.

In short, I see no reason for an ISR low priority be able to stop the execution of an ISR high priority. To know NVIC will make her wait for the end of the most priority ISR to run.

Well, I being wrong, I want to understand it well in deep if you have material that can tell me, I'm looking at Yiu books to see if I can find something else to consolidate what I'm saying.

ilg-ul commented 8 years ago

it might be so, but this is not my case.

my case is when a high priority occurs and interrupts either a thread or a lower priority interrupt.

ilg-ul commented 8 years ago

one more try:

When the resource is also accessed from ISRs, the usual solution to prevent a high priority ISR to run in the middle of a thread or another lower priority ISR, is to temporarily disable the interrupts while using the shared resource.

as a practical example, if you have a list, and on interrupts you want to add an element to it, while a thread might want to get elements from the list, you need to prevent the interrupt to occur exactly when you manipulate the list pointers on the thread, otherwise you end up with a corrupted list.

carlosdelfino commented 8 years ago

yes I understand so well, but when I read the paragraph, there is still a misunderstanding.

I'm trying to find a different way to expose what intuitively see when I read the text.

Perhaps enriches it a bit with an example or a chart.