Enhanced event filtering

Use this forum for requesting small changes in ChibiOS. Large changes should be discussed in the development forum. This forum is NOT for support.
Thargon
Posts: 105
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 11 times
Been thanked: 17 times

Enhanced event filtering

Postby Thargon » Tue May 07, 2019 10:42 am

Hi,

when waiting for events, I encounter situations in my project, where the available chEvtWaitXXX() functions do not provide an optimal solution. It's easy to understand with the following example:

Let there be three events with the masks 0x01, 0x10 and 0x20. Depending on the events received, the thread has to execute different actions. More specifically, whenever event 0x01 occurred it has to do something, and when both events 0x10 and 0x20 occurred it has to do something else.

Right now, I could use chEvtWaitOne() or chEvtWaitAny() to achieve the desired behaviour, but both solutions are not optimal. chEvtWaitOne() would return only one flag at a time and the thread has to accumulate combinations (like 0x10 & 0x20) internally, using multiple calls of chEvtWaitOne() and thus introducing overhead. chEvtWaitAny() might wake the thread if only 0x10 or 0x20 occurred as well, and might even return the event mask 0x31 so that the developer has to handle all possible cases and break up the mask manually, eventually causing overhead and potentially introducing nasty bugs.

So my suggestion is to introduce a chEvtWaitXXX() function, which does not take an eventmask_t as argument, but a function pointer of the form

Code: Select all

typedef eventmask_t (*evtcheckfunc)(eventmask_t pending);
Whenever an event occurred, this callback is executed to decide whether the thread should be woken up. For the example above, the callback would either return 0x01 (-> wakeup), 0x30 (-> wakeup) or 0x00 (-> keep waiting), thus acting exactly as desired.
For most flexible use, it is also possible to use both arguments - event mask and callback - so the callback is only executed if the pending events are not completely filtered out by the mask.

What's your opinion about this idea?

- Thomas

User avatar
Giovanni
Site Admin
Posts: 12289
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 589 times
Been thanked: 502 times
Contact:

Re: Enhanced event filtering

Postby Giovanni » Tue May 07, 2019 11:10 am

Hi,

Right now events cannot handle complex AND-OR conditions, it is just AND or OR.

Why don't just check your conditions before sending the event? you check the condition then send a single event flag using chEvtSignal() if it is met. You can use one event flag for each sub-condition.

For example:
flag 0: A and !B
flag 1: C
flag 2: something else
etc

On the receiver side you just get simple conditions and use chEvtWatAny/One.

Giovanni

Thargon
Posts: 105
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 11 times
Been thanked: 17 times

Re: Enhanced event filtering

Postby Thargon » Tue May 07, 2019 11:58 am

Your solution requires the emitter of an event to know about the receiver, which is very bad code design, imho. An emitter must not care about other emitters or any receivers, it just informs about its own actions.
Of course, I could introduce meta-instances, which accumulate subsets of events and fire a single additional event, but this introduces similar overhead as I described before (probably even worse).

I am not complaining, that I cannot realize the desired behavior. There is just no optimal solution wrt. efficiency.

- Thomas

User avatar
Giovanni
Site Admin
Posts: 12289
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 589 times
Been thanked: 502 times
Contact:

Re: Enhanced event filtering

Postby Giovanni » Tue May 07, 2019 2:57 pm

There are several problems.

The AND/OR conditions represent different thread states (CH_STATE_WTOREVT, CH_STATE_WTANDEVT), the callback would not fall in any of those, it would require another set of "wait" functions and a new thread state with impact on code size and tools (debug plugin would have to be updated to recognize the new state too).

This is a very specific problem without an "easy" solution.

Giovanni

Thargon
Posts: 105
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 11 times
Been thanked: 17 times

Re: Enhanced event filtering

Postby Thargon » Mon May 20, 2019 1:15 pm

I see that there is some a priori knowledge used for thread handling, depending whether it is an AND or OR condition. I also understand that modifying all involved components is not trivial and is probably rather something that should be implemented for a major release.

However, I disagree that my suggestion would require another thread state. Since my idea would allow any logical combination of mask bits, the two existing methods - simple AND and simple OR - are just two specific cases in my much more versatile approach. Thus, you could replace the two states by just one, which handles all cases by just evaluating a callback function, which is specified via the chEvtWaitXXX() function call. Imo, there are only two cases where keeping the "old" thread states would make sense: Maintain (partial) backwards compatibility with other tools and performance optimization, since with this a priori knowledge the callback can be replaced by a static function.

I can implement my approach on the ChibiOS side and provide you a patch, but I don't have the time to check the tools as well. Is there are chance that you would do the second part, if I did the first?

Best regards,
Thomas

User avatar
Giovanni
Site Admin
Posts: 12289
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 589 times
Been thanked: 502 times
Contact:

Re: Enhanced event filtering

Postby Giovanni » Mon May 20, 2019 3:14 pm

Hi,

This is going to break a variety of things, not just backward compatibly, just to name some: code size, OSAL, NIL, test suites, demos, test applications, user/customer applications, other projects depending on ChibiOS.

Considering that it is a pretty specific use case and can be implemented out of the kernel, it is unlikely to happen.

Giovanni


Return to “Small Change Requests”

Who is online

Users browsing this forum: No registered users and 1 guest