Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
93 user(s) are online (48 user(s) are browsing Forums)

Members: 0
Guests: 93

more...

Headlines

 
  Register To Post  

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


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


Edited by rjd324 on 2022/11/2 23:30:31
If liberty means anything at all, it means the right to tell people what they do not want to hear.
George Orwell.
Go to top
Re: What happened to Exec interface's Reschedule function?
Home away from home
Home away from home


See User information
@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.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: What happened to Exec interface's Reschedule function?
Just popping in
Just popping in


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

struct Task *task FindTask(NULL);
// changing the priority will trigger a reschedule
// TODO - User IExec->Reschedule()
oldpri SetTaskPri(task, -10);
SetTaskPri(taskoldpri);


From the autodocs fro SetTaskPri

Quote:

...
FUNCTION
This function changes the priority of a task regardless of its
state. The old priority of the task is returned. A reschedule is
performed, and a context switch may result.
...


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

Go to top
Re: What happened to Exec interface's Reschedule function?
Home away from home
Home away from home


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

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: What happened to Exec interface's Reschedule function?
Not too shy to talk
Not too shy to talk


See User information
@MigthyMaxQuote:
struct Task *task FindTask(NULL);
// changing the priority will trigger a reschedule
// TODO - User IExec->Reschedule()
oldpri SetTaskPri(task, -10);
SetTaskPri(taskoldpri);


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

“The best thing about a boolean is even if you are wrong, you are only off by a bit.”
Go to top
Re: What happened to Exec interface's Reschedule function?
Just popping in
Just popping in


See User information
@rwo

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

struct Task *task FindTask(NULL); 
// changing the priority will trigger a reschedule
// TODO - User IExec->Reschedule() 
BYTE oldpri SetTaskPri(task, -10); 
if( 
oldpri == -10 )
  
SetTaskPri(task, -11 ); 
SetTaskPri(taskoldpri );

Go to top
Re: What happened to Exec interface's Reschedule function?
Just popping in
Just popping in


See User information
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);

Go to top
Re: What happened to Exec interface
Just can't stay away
Just can't stay away


See User information
@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

Go to top
Re: What happened to Exec interface
Just can't stay away
Just can't stay away


See User information
To cause a reschedule with SetTaskPri() it is enough to just do:
struct Task *me IExec->FindTask(NULL);
IExec->SetTaskPri(meme->tc_Node.ln_Pri);

Go to top
Re: What happened to Exec interface
Just popping in
Just popping in


See User information
@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.

Go to top
Re: What happened to Exec interface
Just popping in
Just popping in


See User information
@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:
A reschedule is performed, and a context switch may result.


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:

int __gthread_once (__gthread_once_t *__oncevoid (*__func) (void)) { 
  
__internal_gthread_once_t *once = (__internal_gthread_once_t *)__once
  
  if (
__once == NULL || __func == NULL)
    return 
EINVAL;

  if (
__atomic_load_1(&once->u.i.done__ATOMIC_SEQ_CST))
    return 
0;

  if (!
__atomic_test_and_set(&once->u.i.started__ATOMIC_SEQ_CST)) {
    
/* Started flag was not set so call func now */
    
__func();

    
/* Remember that we are done now. And make all effects prior to this
     * store visible to all the other clients that will read that we are
     * actually done.
     */
    
__atomic_store_1(&once->u.i.done1__ATOMIC_SEQ_CST);
  }
  else {
    while (!
__atomic_load_1(&once->u.i.done__ATOMIC_SEQ_CST)) {
      
/* Allow the other thread to progress quickly but iexec may be not available */ 
      
struct ExecBase *SysBase = *(struct ExecBase **)4;
      
struct ExecIFace *ie = (struct ExecIFace *)SysBase->MainInterface;
      
ie->Reschedule();
    }
  } 

  return 
0;
}


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.

Go to top
Re: What happened to Exec interface's Reschedule function?
Quite a regular
Quite a regular


See User information
Solved. It was put back into 54.16 SDK.

If liberty means anything at all, it means the right to tell people what they do not want to hear.
George Orwell.
Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project