Query RTOS System States possible?

[feanor]

Hello,
I'm curious if it is possible to query the rtos' state, espacially the states "S-Locked" "I-Locked" and "Serving Regular Interrupt" are of interest.
Background of the question is, that I'm implementing a memory-pool based memoryhandling by overloading the operators new() and delete() in C++. If it is possible to request the actual state of the RTOS, the new() function could decide if it should use the chPoolAllocI() or chPoolAlloc() function for providing the requested Memory, and the same for delete() (chPoolFreeI() or chPoolFree()).

Thanks in advance.

[Giovanni]

Hi,

It is possible if you keep the state checker enabled, you can use its state variables:

Code: Select all

/**
 * @brief   ISR nesting level.
 */
cnt_t dbg_isr_cnt;

/**
 * @brief   Lock nesting level.
 */
cnt_t dbg_lock_cnt;

Look in chdebug.c for details.

Of course you could make normal and I-class variants of your functions so you don't have to check the state and just call the right function from the current context.

Giovanni

[feanor]

Hi Giovanni,
thanks for the hints.
Unfortenately, if i would use this variables for checking the states, my code would only be able to run with debugging enabled, am i right?

Another problem is, that new() and delete() do not support any parameters, so it is not possible to provide the necessary state information to this functions.

I've implemented static wrapper-functions with a parameter for let them know if a lock is required or not for creating/deleting objects and made the original constructors/destructors private, but it would have been elegant if there were a possibility to query the actual state and let the new/delete-operator decide on its own whether to take normal or I-class variants.

Would it a big thing to provide this kind of API in ChibiOS?

[Giovanni]

Keeping track of the status is exactly what those two variables do, even if we don't call those "debug" the overhead would be the same. Probably it would be possible to make setting those variables a bit more efficiently by inlining that code and a query function could be introduced but I would not make that functionality a core one because performance considerations.

You may check the interrupt status but that would not be portable, I am considering introducing a lock-check in the port layer in order to make it portable.

Giovanni

[jcbarlow]

You may check the interrupt status but that would not be portable, I am considering introducing a lock-check in the port layer in order to make it portable.
Giovanni

Invoking the C++ new operator within interrupt handler code seems like a really bad idea anyway.

[feanor]

Hi,
why is it worse using an overloaded new-operator which acts on a ChibiOS memory pool with chPoolAllocI() than using chPoolAllocI() directly in an interrupt-context?

[jcbarlow]

My view is that ISR code should generally be as short and fast as practical. It should always be fully deterministic.

Dynamic memory allocation invariably involves having to deal with the "out of memory" condition.

I can perhaps imagine some peculiar cases where explicitly calling chPoolAllocI() in an ISR might be useful, though I would do my best to avoid it. Having such a call happen implicitly within some nested constructor is IMHO a recipe for an intermittent, load dependent bug. I'm pretty sure at least some of my grey hair resulted from chasing those sorts of bugs.