how to restart a thread?

Hi.

 

I need, during the execution of the application, to be able to restart a thread. I am trying to do it in the following way:

while (1) {

if (sDrivers.niReset==2) {
    status=tx_thread_reset(&http_server_thread);
    if (status==TX_SUCCESS)
      sDrivers.niReset=0;
}

if (sDrivers.niReset==1) {
   status=tx_thread_terminate(&http_server_thread);
    if (status==TX_SUCCESS)
        sDrivers.niReset=2;
}

tx_thread_sleep(100);

}

but it doesn't work properly for me.


What would be the correct way to do it?

 

Thank you.

Regards

  • From the ThreadX manual :-

    However, if you look at the source code for the function tx_thread_reset() :-

     

    and

     

     

    after a call to tx_thread_reset() the thread will be in the suspended state, ready to run from the entry point, a call to tx_thread_resume() will be required as well.

     

    I suspect the API tx_thread_reset() was added, but the documentation not updated.

  • Hello,

    I'm running exactly this method to stop and restart a thread that is using a NetX framework. I have a problem on the other hand with the dhcp_client framework which does not restart.
    if i don't delete the dhcp module before terminating my thread at reinit i get a g_dns1_err_callback_internal error.

    Which correct method should I use with the DHCP module ?...

    I use 2 threads one for the MQTTS Ethernet, the other for Web by Wifi.
    each uses a separate dhcp module, and therefore each managed by its own thread.
    The two threads do not run at the same time, when one starts up, the thread stops and resets the other thread, and vice versa.


    Thank you for your help.

    Eric

  • What is the sequence of API calls you use for NetX and each NetX applications during the shutdown and restart of the thread? What are the return values from each of these API calls, are there any errors?

    g_dns1_err_callback_internal is part of the generated code of the SSP, that is used during the initialisation of the DNS client g_dns1, it is called if there is an error in creating the packet pool used by the DNS client, or creating the DNS client. Do you delete the packet pool and shut down the DNS client as part of your restart proceedure?

  • Hi Jeremy,

    thanks for your new help !
    No I don't delete the packet pool used by DNS... But I delete, the DHCP and the DNS.before to reset the thread. I will try your idea.... (I have no errors when I delete the modules).

    In general, would it not be possible when one chooses "Autoinitialization" for elements in a thread, that when one terminates the thread, the system automatically closes the elements created with "Autoinitialization"?

    Best Regards,

    Eric

  • No, all autoinitialisation means is that the SSP will generate the code to initalise that particular module, it will still need to be shutdown properly using the correct API sequence before the thread terminated.

  • Hello Jeremy,
    Sorry to answer so late, but a lot of work at the moment...

    So I reworked the stop of my two threads.
    When the thread that manages the 2 threads, decides to stop one of them, it launches a stop request event and waits for a response from the thread that it is in a state to stop, (i.e. that it has closed all the components (Netx Web http or MQTT, IP, as well as the pool...), which are initialized at the thread entry.
    When the message is received by the "master" thread, it launches the thread terminate command.

    To restart it, later, it launches the TX_Reset command, followed by TX_Resume.
    These first commands work well the first time (after a ROP). However, when they are sent after a stop, the thread does not restart...
    Yet I have no error... Neither at the close, (terminate) nor at the Reset and Resume... :

    Here is the state in which the thread is after the request of Reset and Resume, (with RTOS Ressources View):

    Is this semaphore blocks the resume? Why on the second Resume ? What I do forget?

    Here is the delete sequence before send message for terminate :

    And the framework on my thread :(for Netx Web HTTP...)

    Thanks for your help...

    Eric

  • It looks like the thread is stuck in the autogenerated function tx_startup_common_init() :-

    that is the first thing that is called at the start of the thread.

  • Hi Jeremy,

    Yes and it's very annoying...
    How can I unblock it? How can I get my hands on this internal semaphore?...
    Where can I find a documentation that could explain this mechanism in detail? The product should be delivered at the end of the month... And I'm already struggling for several weeks with this problem of thread stop and restart!
    Thanks in advance.

    Eric

  • The semaphore is a global symbol :-

    that is at the top of main.c. The API for the individual X-Ware components are defined in the documentation for each of the X-Ware components, however I am not aware of any document that describes how they all interact.

  • It is very penalizing, how can I get out of it?
    What course of action should I take?

    Regards,

    Eric

  • You just need to put to the semaphore while restarting the thread, e.g. to restart the blinky_thread :-

    extern TX_THREAD blinky_thread;
    extern TX_SEMAPHORE g_ssp_common_initialized_semaphore;


            status = tx_thread_terminate(&blinky_thread);
            if (TX_SUCCESS != status)
            {
                __BKPT(0);
            }

            status = tx_thread_reset(&blinky_thread);
            if (TX_SUCCESS != status)
            {
                __BKPT(0);
            }

            /* Put the semaphore to allow the restarted thread to run through tx_startup_common_init() */
            status = tx_semaphore_ceiling_put(&g_ssp_common_initialized_semaphore, 1);
            if (TX_SUCCESS != status)
            {
                __BKPT(0);
            }

            status = tx_thread_resume(&blinky_thread);
            if (TX_SUCCESS != status)
            {
                __BKPT(0);
            }

    alternatively don't create the thread you want to restart in the configurator, create in manually in your code with a call to tx_thread_create(), then it won't run tx_startup_common_init() at all (you can still add any required drivers or stack in the configurator, just add them to a different thread).

    Another option is to handle the shutdown and restart of the IP instance in the thread without restarting the thread.

  • Thanks Jeremy for these ideas.
    I will try and keep you posted.

    Regards,

    Eric

  • Hello Jeremy,
    I tried to add the put semaphore function between the reset and the resume of the thread, (solution 1 proposed).
    It solves well my problem of blocking at the init of the thread.

    Thank you!

    Eric