Mutex on Multicore

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Level 2
Level 2
First like received
I am working on tc37x aurix. I need to use two cores for parallel processing and faster performance.There are common data structures shared between two cores. So should I use locking and unlocking concept for this
implementation?Or Is there any other way possible with aurix?

I could not find any documents for multicore programming or sample codes related to mutex locking and unlocking.
Could someone please help me to sort out this issue?

Thank you in Advance.

Aiswarya Jayan
2 Replies
100 solutions authored 5 likes given 50 likes received
Do not use Cached memory for the data. Then use an atomic operation.

2.4 Semaphores and Atomic Operations
The following instructions read and/or write memory in atomic fashion:
• LDMST (Load, Modify, Store)
• SWAP.W (Swap register with memory)
• ST.T (Store bit)

LDMST uses a mask register to write selected bits from a source register into a memory word. However it does not return a value, so it can not be used as an atomic "test and set" type operations for binary semaphores. The SWAP.W is provided for this purpose. If memory protection is enabled, the effective address of the LDMST, CMPSWAP.W, SWAPMSK.W, SWAP.W or ST.T instruction must lie within a range which has both read and write permissions enabled.

The CMPSWAP.W instruction conditionally swaps a source register with a memory word. The SWAPMSK.W instructions swaps through a mask the contents of a source register with a memory word.

The execution of an atomc instruction forces the completion of all data accesses symantically ahead of the instruction. This ensures that any buffered state is written to memory prior to the atomic operation.
Level 6
Level 6
50 likes received 50 solutions authored 100 sign-ins
Additional support for atomic variables has been introduced in the current v6.3r1 release of the TASKING TriCore tools. The release notes include the following details:

C11 Language and Library Support
This release supports C11 language and library features as defined by the ISO C standard. With the C compiler option --iso you select the ISO C standard. C90 (option value '90') is also referred to as the "ANSI C standard". C99 (option value '99') refers to the ISO/IEC 9899:1999 (E) standard. C11 (option value '11') refers to the ISO/IEC 9899:2011 (E) standard. C11 is the new default. All unconditional (mandatory) C11 features are supported. Of the conditional features which are introduced by C11 the Atomic feature is supported. Support can be checked by means of the conditional feature macros as defined by the C standard (section

Atomic Variable Support
The TASKING TriCore C compiler now supports atomic types (by means of the _Atomic type qualifier) and the features defined by the standard header file (the __STDC_NO_ATOMICS__ macro is 0 for TriCore architectures 1.6.x and 1.6.2). The compiler restricts atomic type qualification to those types and to those operations for which the hardware allows a lock-free implementation. The compiler only implements the strictest memory ordering: memory_order_seq_cst. This implies that all less strict orderings are also supported, but support for those is sub-optimal.

You can now use __uncached__ or __attribute__((uncached)) on variables to instruct the linker to allocate the corresponding variable in a non-cached memory segment. Extensions were made to the system LSL files to identify cached memory segments (new LSL keyword 'cached'). If a variable is declared with the 'uncached' attribute, its corresponding section name contains the substring ".uncached", for example .zbss.uncached.my_module.my_atomic_var. Atomic variables automatically imply the attribute 'uncached'.

Best regards,
Ulrich Kloidt

TASKING tools support