Global resources are not allowed (with queued spinlocks)

[awall]

Hi,

I'm using a global resource in two tasks, assigned to two different cores (TriCore Tc27x). In the OIL file the OS object has the following attributes (among others):

Code: Select all

STATUS = EXTENDED; 
USERESSCHEDULER = TRUE;
KERNEL_TYPE = ECC1;
REMOTENOTIFICATION = USE_RPC;
SPINLOCKS = QUEUED; //global mutexes do not work with this option enabled for some reasons

I also defined a RESOURCE object using it as a global mutex and assigned it to a task on the master and slave core.

Now generating the ErikaOS config files with RT_Druid ends up with the following error: "com.eu.evidence.rtdruid.internal.modules.oil.exceptions.OilCodeWriterException: Global resources are not allowed"
The oscfg make works fine with the attribute "SPINLOCKS = QUEUED" disabled, i.e. using the trivial implementation.
Is this a bug in ErikaOS or do I do something wrong using the resource as a global mutex.

regards,
a.wall

[AlTi]

Hi,

I´m using a TriCore TC27x in a multicore configuration, too. Global resources aren´t available in ERIKA Autosar OS with the RPC implementation (please read in http://erika.tuxfamily.org/wiki/index.p ... ementation for more information).

The intended mechanism for mutual exclusion between different cores is the spinlock mechanism. Therefore, just replace your global resource with a spinlock.

I hope, this helps.

[paolo.gai]

Yes, correct. Note that the "original" implementation with the "global resources" that i did in 2002 is still available on the Nios II port in the wiki.

Unfortunately it is somehow not easy to port the global resources and the queuing spin-locks to the AUTOSAR OS implementation, because:
- AUTOSAR has its own spinlocks, so no global resources...
- queuing spin-locks are out of the AUTOSAR OS standard, and in any case the G-T implementation I used is not much applicable because when an OS Application terminates all threads doing a spin-lock must be stopped... which is not implementable in an easy way with G-T.

G-T --> G. Graunke and S. Thakkar, Synchronization algorithms for shared memory multiprocessors. IEEE Computer, 23(6):60-69, June 1990

Ciao,

PJ

[awall]

Thank you for your anwers.

Now, using Spinlocks I've got another problem, which I believe might be a bug in the OS. As long as I had code with only a view spinlocks declared in the oil file everything worked well.
As soon as I declared more spinlocks than the sum of tasks and ISR2 on one core, I noticed impermissible writes to some completely different variables linked next to the following array declared in eecfg.c.

Code: Select all

/***************************************************************************
 *
 * Spinlock
 *
 **************************************************************************/
    TaskType EE_as_spinlocks_locker_task_or_isr2[EE_MAX_TASK + EE_MAX_ISR2] = {
        EE_NIL, EE_NIL, EE_NIL, EE_NIL, EE_NIL, EE_NIL, EE_NIL, EE_NIL
    };

In my code I've declared 8 tasks and one ISR2 for core 0 and 23 spinlocks. Hence, this array has a size of 9 in my example.
In ee_as_spinlocks.c I found this line of code

Code: Select all

EE_as_spinlocks_locker_task_or_isr2[SpinlockId] = current;

When I try to lock the spinlock with SpinlockId=11 I have very unexpected behavior of the OS.

Is there an intended restriction on the amount of spinlocks or is this a bug?

thanks,
AW

[paolo.gai]

Sorry to say but... bug.

The array should have the dimension of the spinlocks and not of the tasks. We are going to fix both the code and the RT-Druid configurator.

PJ

[awall]

great!

when can I expect a new release with this bugfix?

[paolo.gai]

We are rather busy in the latest days, but we'll try in 1-2 weeks time.

PJ

[paolo.gai]

One possible workaround for now:
1- adding dummy tasks in the system. in this way, the array will become bigger and you'll not have that problem
2- generate the code, then hand-modify the generated code, then disable the OIL generator and build again to compile again the system without recompiling the OIL file.

PJ

[nicola.serreli]

Hello,

the last nightly build contains the fix.

You can update your installation using the update site: http://www.evidence.eu.com/erika-builds ... uid_250_nb

best regards,
Nicola