ThisThread get_name()

[marcemmers]

Description

Added function to get the name of the current thread to ThisThread.
Comes in handy when debugging and doesn't have any impact if not used.

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[X] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

[kjbracey]

Not totally sure about this, but I guess it's useful, and there's no other way to get the info other than going to the CMSIS-RTOS APIs.

[kjbracey]

Could also be NULL if the thread has no name. (Possible in CMSIS-RTOS, even though the Thread object likes to put in "application_unnamed_thread")

[kjbracey]

You may be right here - I think it actually returns current foreground thread if called from ISR.

Wasn't inconsistent though - documenting it as returning NULL from ISR is perfectly logical.

Saying it returns NULL from ISR but then saying you can't call it from ISR would be inconsistent.

[kjbracey]

Although the new documented behaviour is maybe what you get from RTX osThreadGetId, I don't think it's actually what we would want from ThisThread::get_id, given the name.

Fixing implementation to match documented behaviour would be better I think. Or specifying it can't be called from ISR.

It was supposed to be a drop-in replacement for Thread::gettid(), which never specified ISR behaviour, but said it worked. Hmm.

[marcemmers]

I misunderstood the "Cannot call" then, thinking it is possible to call but wouldn't function. Instead the functions that say they cannot be called from ISR crash?

It seems to me that both osThreadGetId and osThreadGetName can be called from ISR context. Only osThreadGetName returns NULL even if the ID is valid in ISR context.

It does make sense to block both get_id and get_name from being called in ISR context because there is no ThisThread if you are in ISR context. All other functions in the namespace are already blocked from ISR context so why should get_id be allowed?

[kjbracey]

I misunderstood the "Cannot call" then, thinking it is possible to call but wouldn't function. Instead the functions that say they cannot be called from ISR crash?

Often, yes, sometimes only enforced in a debug build. Or behaviour may be undefined.

It seems to me that both osThreadGetId and osThreadGetName can be called from ISR context. Only osThreadGetName returns NULL even if the ID is valid in ISR context.

CMSIS-RTOS 2 docs explicitly say osThreadGetName can't be. They say osThreadGetId can be, but don't say what it does. I thought it returned NULL, but current implementation seems to return running foreground thread.

It does make sense to block both get_id and get_name from being called in ISR context because there is no ThisThread if you are in ISR context. All other functions in the namespace are already blocked from ISR context so why should get_id be allowed?

I wrote that, and I think I allowed it because

• Thread::gettid() allowed it, and this was supposed to replace it
• I thought I was just documenting existing behaviour
• I thought returning NULL to say "you're not in a thread" was potentially useful, and maybe a way of deciding what to do on that basis.

If it doesn't actually return NULL in that case, it no longer makes sense to be ThisThread::get_id - it would be ForegroundThread::get_id. So I agree with saying it's not allowed in ISR. We could conceivably put in a local "are we in IRQ context" test, but I don't really want to go there.

[kjbracey]

Note that error cases in RTX call EvrRtx... functions. Those are trapped and trigger mbed_error in many cases, so osThreadGetName from ISR may well die and not return NULL.

(Maybe debug build only?)

[marcemmers]

I was looking at the cmsis_os2.h file instead of at the real docs. You're right about the osThreadGetName and I will change my comments.

Noticed the EvrRtx call but didn't know that could lead to an mbed_error call, thought it was only meant to record some events.

So the question remains, what to do with the get_id.
Should I leave it be so it can be looked at later on? Should i note that it cannot be called from ISR but not enforce it?

[kjbracey]

I'd leave the get_id call to another PR. Needs separate discussion. I'd initially suggest saying it can't be called from ISR, and not enforce, so just docs change.

[cmonr]

@marcemmers A small astyle nit and we can get CI started.

[kjbracey]

I still want to leave the get_id change out - it needs more work/discussion. I'm fine with the get_name addition once the formatting change is done. Also, squash the PR.

[cmonr]

CI started

[mbed-ci]

Test run: FAILED

Summary: 6 of 7 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_build-GCC_ARM
• jenkins-ci/mbed-os-ci_build-ARM
• jenkins-ci/mbed-os-ci_build-IAR
• jenkins-ci/mbed-os-ci_mbed2-build-GCC_ARM
• jenkins-ci/mbed-os-ci_mbed2-build-IAR
• jenkins-ci/mbed-os-ci_mbed2-build-ARM

[alekla01]

CI restarted

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 2
Build artifacts