I-class Delegate Threads? Topic is solved

[TKorho]

Ref: ChibiOS Delegate Threads

Delegate Threads does not seem to work from ISR routine (timer callback).

Could the thread delegation be expanded to I-class use? The chMsg doesn't seem to have I-class send. I don't understand the mechanics enough if there is something to stop them being used from locked contexts.


I of course use the event flagging currently, as per the very good example on the web page! Thank you for that. That works very well. But it would be nice to have one esthetic mechanism to gap the common handler thread moat. And with delegate methods it would be easy to combine several functionalities under that same centralization.

[Giovanni]

Hi,

Messages can't be made to work from ISR because it is a synchronous mechanism, you can't "sleep" inside an ISR while another thread is handling the delegate function.

Giovanni

[steved]

I think I read somewhere that FreeRTOS has a construct similar to this, where from within an interrupt you could trigger the execution of any routine from within a thread.
Not difficult to set up using event flags and a worker thread, but maybe there would be efficiencies derived from a specific construct.

[Giovanni]

Hi,

How do you do the waiting for the thread to return the result of the function? you cannot wait in an ISR. Function parameters in the IRQ stack are another issue, delegate threads fetch parameters from the stack of the delegating thread without copying.

In OSLIB the asynchronous equivalent of delegates are "jobs" which are just sent without waiting for a result, those can be posted from ISRs. It is a specialization of mailboxes/pools where a "job" structure (function, argument) is sent.

Giovanni

[TKorho]

My typical paradigm doesn't require the return value, so I didn't think of that. I now see that the msg behind the delegate is synchronous, that's not good.

I was thinking more of an esthetic and simple API to act from all kinds of contexes, making it easier to make the requests from any kind of situation. An example is sending out status information over the SERIAL, from several places inside the code. For eg from timer it now needs some extra effort. I can encapsulate the event flags in similar looking local interface for now.

I am not yet acquinted with the jobs, I'll look into it. On the first look it seems powerful, but less clean than delegate, but I understand the reasons. And then again it also can probably be encapsulated to be look simpler to call.

[Polux]

Hello,

What about task/thread priorities ?

Angelo

[Giovanni]

What about task/thread priorities ?

Hi,

I don't understand the question, could you be more specific?

Giovanni

[Polux]

Hello,

There is a calling thread, with its priority. And a function in the delegate thread, with its priority.
If the caller thread has a lower priority, and calls the function wich is in a higher priority thread, what is the priority during function execution ? The caller or the delegate priority ?
And what in the opposite case ?

Or, may be, I am missing something ?


Angelo

[Giovanni]

Hi,

It is a the delegate priority but it is a good point, perhaps an escalation mechanism could be useful if the caller has higher priority than the delegate.

Giovanni

[Polux]

Hello,

Is it possible to let the delegate thread run its own code ?
As an exemple: The delegate thread would make some CRC checks, controls, etc... once in a while.

Code: Select all

/* Messages dispatcher loop.*/
while (true) {
  chDelegateDispatchTimeout(MY_TIME) {
  callMyOwnfunctions ();
}

But external caller will be delayed until the delegate thread end its own work.

Angelo