• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 2615 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Global variables protection across threads

Franck
Intellectual 685 points
Other Parts Discussed in Thread: TMS320DM6437

I am using multiple threads with Bios 5.41 that access global variables (TMS320DM6437). Because I could not clearly identify in documentation how global variables are managed by the compiler and the Bios thread context switching, I used to always protect all global variables by semaphores.

But I am pretty sure this is overkill and would like to know if someone could give me some hints.

Thanks

  • 0
    TI__Mastermind 24340 points

    Please see this post:

    http://e2e.ti.com/support/embedded/f/355/p/53456/189540.aspx#189540

    Let me know if it does not answer your question.

    Any task can access any global variable. So semaphores would be good in case you have a specific order that could be affected by preemption/task priority.

  • 0 in reply to Mariana
    Intellectual 685 points

    Thanks Mariana for the reply, but I would like some additional details about atomic operations on global variables.

    If I am writting my application in C, are all data types accesses (from a simple char data type to a long long data type) guaranteed to be converted to atomic operations at the assembly level?

    For example, let's assume I declare na unsigned long long global variable (64 bits). If in thread A I set this variable to 0 and in thread B I set it to 0xFFFFFFFFFFFFFFFF, is there a guarantee that the operation is always atomic in such a way you never end up with a partially updated variable like 0x00000000FFFFFFFF after one thread preempts the other one. I wonder if this is something that could happen because of the need to decompose some operations that "look like" atomic at the C-language level, but actually ends up in two or more 32-bits operations.

    Maybe what I just suggested is simply impossible, or there are some mechanisms in the Bios task switching to prevent such situations. That is what I would like to demystify.

    Thanks

  • 0 in reply to Franck
    TI__Mastermind 24340 points

    Hi Franck,

    Please see the document below for more information:

    http://www-s.ti.com/sc/techlit/spru732

    Franck said:
    For example, let's assume I declare na unsigned long long global variable (64 bits). If in thread A I set this variable to 0 and in thread B I set it to 0xFFFFFFFFFFFFFFFF, is there a guarantee that the operation is always atomic in such a way you never end up with a partially updated variable like 0x00000000FFFFFFFF after one thread preempts the other one. I wonder if this is something that could happen because of the need to decompose some operations that "look like" atomic at the C-language level, but actually ends up in two or more 32-bits operations.

    Yep, you are right, the individual assembly instructions should be atomic, but sometimes manipulating a global might take more than one instruction indeed. So you are in the right track using semanphores.

    When more than one thread need the same resource, you have some possibilities:

     

    1) Assign concurrent threads to the same priority – FIFO

    + No possibility of conflict, no memory/time overhead, easy

    - Forces involved threads to be same priority

     

    2) Disable interrupts during critical sections

    + Needed if a hardware interrupt shares data

    - Affects response time of all threads in the system

     

    3) Disable SWI/TSK scheduler during critical section

    + Assures one SWI/TSK to finish with resource before another begins

    - Affects the response times of all other SWIs

     

    4) Raise priority of SWI/TSK during critical section

    * Set priority to highest priority which may access the resource

    + Equal priority SWIs/TSKs run in FIFO order, avoiding competition

    - Can affect response times of SWIs/TSKs of intervening priority

     

    5) Use atomic functions on shared resources

    + Imposes minimal jitter on interrupt latencies

    - Only allows minimal actions on shared resources

    See chapter 2.1 of the http://www.ti.com/lit/pdf/spru403

     

     

    6) Regulate access rights via Semaphores

    + No conflict or memory/time overhead of passing copy

    - Multiple semaphore schemes can introduce problems