• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 593 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.

CC3220MOD: pthread and FreeRTOS - Tasks manipulation

Vincent Vuarnoz
Expert 2545 points
Part Number: CC3220MOD

Hi community,

We are using FreeRTOS and are currently trying out the posix layer. 

It seems to us that it is NOT straight-forward to, for example, suspend and resume a task. pthread_cancel can be used to suspend, but what about resuming it ?

Are we missing something ?

  • 0
    TI__Mastermind 40965 points
    Hi Vincent,

    pthread_cancel() isn't meant to be used to suspend threads, as that function is meant to be used as a method for one thread to force another thread to exit and will destroy the cancelled thread's context outright. Thus, there is no function to uncancel threads.
    I don't think that suspending and resuming threads explicitly is best practice, but if it is needed in your application I suggest you take a look at this link here for how you could effectively suspend and resume threads:
    stackoverflow.com/.../what-is-the-best-solution-to-pause-and-resume-pthreads

    Let me know if you need more clarification or have further questions on this topic.

    Regards,
    Michael
  • 0 in reply to Michael Reymond
    Expert 2545 points
    Hi Michael,

    Yes, I agree is not best practice. But I couldn't come with a better solution, maybe you will.
    It's releated to that issue (e2e.ti.com/.../2955724
    We have a CC3220 acting as a station, and listening to a udp port. So a task is created only to listen to that port, therefore it is needed to start that task only after the station has connected and sockets have been properly initiated. Then, if the station disconnects, that task has to be suspended and sockets be properly closed. Etc, etc....
  • 0 in reply to Vincent Vuarnoz
    TI__Mastermind 40965 points
    Hi Vincent,

    I think that for your application, you shouldn't need to have to rely on an external thread suspending/cancelling/killing the udp listening thread. Instead, you should probably think of getting your udp task to close its own socket, free its own resources, and then exit or return gracefully. You may want to use a cancel flag or semaphore set by the main thread when it detects some condition like a Wi-Fi disconnect. Your udp listening thread can check for this flag periodically, and then have it close its socket and then exit simply by performing a return() once this condition is detected.

    Regards,
    Michael