The docs say:

Note that some flags (currently the three most significant bits) are used by core functions and should not be set by the user. They can be waited for.

But then it goes to define only two reserved flags. For this reason I'm marking it as an API change.

@jcarrano

• Clarified doc text
• Move THREAD_FLAG_EVENT from event.h to thread_flags.h, for better visibility

the three in the text for reserved flags is probably a leftover since #7543

When you are woken up by THREAD_FLAG_IRQ_SERVICED, how do you know the flag was set by the i2c IRQ and not by any other IRQ?

Good question! There is a potential for collisions here, so developer needs to ensure that the ISR only sets the flag when a thread is actually expecting it. In the i2c case we only enable the IRQ from the i2c module when we perform a transfer, so the thread will be expecting a thread flag to become set. The i2c module isr will not even know which thread to send the flag to unless there is a thread that has claimed the bus (i2c_acquire). For the network device, we know that each gnrc_netif thread is only managing a single device, so each network device can set the flag on its assigned thread without risk, as long as the netif thread does not do other things as well.
Do you think we should split this into two or more flags? THREAD_FLAG_PERIPH_IRQ, THREAD_FLAG_NETDEV_IRQ

Do you think we should split this into two or more flags? THREAD_FLAG_PERIPH_IRQ, THREAD_FLAG_NETDEV_IRQ

Where's the limit? What if, say a SPI or UART device also sets THREAD_FLAG_PERIPH_IRQ? I understand that this shouldn't happen if all peripheral calls are blocking because then a single thread can only use one peripheral al the same time, at least for protocols where only the host can start a transmission/reception. For things like UART or a I2C in slave mode, one would have to make sure that the flag is not set by a RX IRQ, because a RX may happen at any time and there might be some unrelated code waiting for that flag.

Another option would be to use the flag as is and then check the actual cause, similar to how a shared interrupt line works in hardware.

@jcarrano we lose the benefit of the lightweight thread flags if we multiplex events like this. What you suggest is similar to what sys/event does.

@gebart Then we should reserve ALL thread flags (or maybe leave one or two user-defined):

• It is a limited resource, that requires care to be used properly.
• If any other code uses a thread flag there is a potential for bugs.
• There should be an agreement on what each flag does so that different modules don't collide.
• It will save us another "API-Change" in the future.

I'd like it to make it clear in the documentation: "This thread flag should only be used when for waiting for a peripheral IRQ, and only when it is known there is only one interrupt (the one corresponding to the peripheral being waited for) that can set the flag"

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.