New multi-core kernel for AmigaOS 4 shown at Pianeta Amiga!

	Bottom Previous Topic Next Topic
Register To Post

« 1 ... 6 7 8 (9)

joerg

Re: New multi-core kernel for AmigaOS 4 shown at Pianeta Amiga!

Posted on: Yesterday 16:59 #161

Home away from home

@Georg
Quote:

Are you sure? Permit() really should only trigger reschedule if one is pending. Like when another task was Signal()ed while in Forbid state.

In AmigaOS 0.x-3.9 and maybe AROS, but ExecSG isn't based on any old AmigaOS exec sources (there were none anyway, only useless m68k asm code) nor did it try to re-implement it 1:1.
A lot in ExecSG is very different to older exec versions, incl. the task scheduler.

Quote:

Otherwise for example each and every ObtainSemaphore() call would trigger a reschedule, because I guess also in AOS4 it still is implemented using Forbid/Permit protection (no matter if slow or fast (uncontended) path).

No idea how the old signal semaphores are implemented in ExecSG, and Procure()/Vacate() is probably not supported at all. Maybe they are, at least partially, based on Mutexes instead.
The IExec->Mutex*() functions aren't based on Forbid()/Permit() but on PPC atomic instructions.

Georg

Re: New multi-core kernel for AmigaOS 4 shown at Pianeta Amiga!

Posted on: Yesterday 18:06 #162

Just popping in

@joerg

Quote:

No idea how the old signal semaphores are implemented in ExecSG

Would be easy to test, but I have no access to AOS4 at the moment. Only ever had Classic PPC Version with WinUAE on older PC that is stored away.

Test: have a Test task block in ObtainSemaphore() on a semaphore that never gets released and look what the task's TDNestCnt is while it's blocked waiting.

Quote:

The IExec->Mutex*() functions aren't based on Forbid()/Permit() but on PPC atomic instructions.

Atomic instructions alone are not enough. It works for the "fast-path". That is when at time of the MutextObtain() call the mutex is not owned by anyone. If this isn't successful then the mutex must go the "slow-path" way. That involves thinks like adding the task to the wait queue of the semaphore. This is not safe without something that prevents other tasks from doing the exact same thing at the same time.

The MutextObtain() autodocs themselves say:

-->8--

"if the mutex isn't locked when this function is called on it, it will acquire the lock without the use of Forbid/Permit locking"

-->8--

This suggests that the slow-path uses Forbid/Permit. But to be sure could be tested same way as obtainsem-test.

To test whether "Forbid()/Permit()" really always triggers reschedule could be tested like this:

- create a pri 0 task that busy loops in the background and does nothing else. That task would always be TS_READY.

- in the main task (pri 0) in a loop do:


#define Reschedule() Forbid();Permit();

while(!CheckSignal(SIGBREAKF_CTRL_C))

{

  int a,b,c,d;



  a = SysBase->DispCount; Reschedule();

  b = SysBase->DispCount; Reschedule();

  c = SysBase->DispCount; Reschedule();

  d = SysBase->DispCount; Reschedule();



  if (a == b && b == c && c == d) printf("Not rescheduled: %d\n", a);

}

Assuming SysBase->DispCount contains task dispatch count in AOS4 (like it does in AOS Classic)

Register To Post	« 1 ... 6 7 8 (9)
	Top Previous Topic Next Topic

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