What happened to Exec interface's Reschedule function? (SOLVED)

This was removed in 53.34 SDK. It is causing a build issue for cross compiler.

@rjd324

Maybe they renamed it?

Don’t think its available in public version of ExecSG, nor should you need it in a cross compiler, its not running on/from AmigaOS after all.

I found a workaround how to trigger a reschedule with exec without the official Reschedule method:



From the autodocs fro SetTaskPri

Quote:

I just wanted to document it here, in search for an answer.

As far as i can tell, in the "soon to be released" SDK update, this function back on the track.

@MigthyMaxQuote:

Well I beleave this will fail to reschedule if the Task already is running at pri. -10.

@rwo

You probably right. So to make sure that the task prio is really different, the work around solution should be:

What's wrong with just using the existing priority and adding or subtracting one to it for the first call.

ie;
BYTE oldpri = SetTaskPri(task,  (task->tc_Node.ln_Pri - 1) );
SetTaskPri(task,  oldpri);

@colinw

Probably best to always subtract, you don't want to step on any other tasks' future CPU access just to make one reschedule.

But yeah, that was my thought too (without knowing exactly how to code it in AmigaOS).

Best regards,

Niels

To cause a reschedule with SetTaskPri() it is enough to just do:

@salass00

You are totally right, I havn't looked at that function for ages.
If the 'task' argument is the same as the calling task, it always does
a Reschedule(), so the priority change kludge is unnecessary.

@colinw

You are right, that's another workarounds for the missing reschedule method. But still a workarounds.

@salass00

This might work. Depends on why you are calling IExec->Reschedule() from an application?.

My personal meaning is, if we take a wider look at where IExec->Reschedule is used and how, I think 99%
of the usage is not correct, and the remaining 1% usage is probably just for os/kernel related stuff.

Let me explain why i think that 99% of the usage is wrong. First of all from an application point of view,
what to you gain from a call to IExec->Reschedule()? BTW i couldn't find any documentation about it in any
of the available SDKs. So i assume it does something similar as the side effect of calling SetTaskPri;

Quote:

The reschedule per se is transparent for the calling application, but the optional context switch can be
misused to synchronized task/process. Like the implementation of pthread_once method of the gcc compiler at
https://github.com/sba1/adtools/ uses it:



To understand what it does the man page of pthread_once might help. It ensures that the __func method gets only called once,
regardless how many tasks/processes/threads simultaneously or each after another calls pthread_once. The trickiest part of
the implementation is if more than one task/process/thread calls pthread_once simultaneously, or better said, if task/process/thread A
still executes __func and during that additional tasks/processes/threads calls pthread_once. Because currently with one CPU core no real
multitasking is possible, one of the additional tasks/processes/threads would starve task/process/thread A. To avoid that the author
used IExec->Reschedule to give process A time on the CPU. Mainly relaying on that the optional context switch is performed, and A gets
process time on the CPU. With lowering the task pri it makes this even more likely, especially if A has a higher priority.

If in a future the AmigaOS kernel can utilize multiple CPU/Cores, the solution could break. With missing documentation of
IExec->Reschedule there are a lot of question raising in my head for a future multi core system, what a call of
Reschedule will result in...

a) just reschedule the tasks on the core where my calling tasks run?
b) all cores?
c) any other core expect the core my task runs on
d) randomly one core of all available

Some of them don't sound reasonable, but if the behavior isn't a/b you can build scenarios where the implementation above won't work.
And i might think a solution b wouldn't be good to overall performance of the os on a multiple core setup.

For the above implementation a better solution for replacing IExec->Reschedule would be to have the calling task to go to "sleep". But
there isn't a sleep function in Exec, just the Delay method in DOS, which again might not be callable if the calling task isn't a Process
or at least hasn't setup a MsgPort as mention on in the AutoDoc of DOS.

And for me i think it is correct that the SDK doesn't publicly offer the Reschedule function. It should be use by normal applications.

BTW on the pthread branch of afxgroup clib2 there is different implementation of pthread_once, which don't use a sleep of reschedule
kind of mechanism to handle the task/.. synchronization. Instead it's solution builds upon a look. Which in my opinion is even nicer,
because of no looping (and the threads gets put to sleep and just gets wake up from the os
than they can continue there work.

Solved. It was put back into 54.16 SDK.