question

spanchal avatar image
spanchal asked spanchal posted

How to determine if a given signal is Activated ?? How to Terminate a thread ??

Hello members,

 

The signalActivate action is used to activate a named signal. Is there a way to determine from iTest which singal has been activated by any thread? In other words I need a way to find which singals are Activated at any given time ?

 

Also, iTest allows one to start a step/procedure in a new thread (witha given name) from the main test. Is there a method/action to terminate this thread from the main?

 

Appreciate your help.

 

Thanks,

spanchal

iTestfeature request
10 |950

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

1 Answer

·
sreenath avatar image
sreenath answered sreenath posted

SignalActivate will activate the signal and releases the waiting signal. The name of the signal should be same on both the steps.

 

In the screenshot I am waiting for the signal "Signal_1" in main thread that is activated in the second thread. So in this case my main thread will halt its execution till the same named signal is recieved from second thread. We can verify from the response of SignalWait step whether the particular signal is activated or not by adding the analysis rule to the step.

 

We can kill the thread at any step by using the Abort thread action in the analysis rule for the step. 


signal.JPG (61.6 KiB)
signal1.JPG (75.4 KiB)
2 comments
10 |950

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

koelze avatar image koelze commented ·

There's no way to query whether a given signal is activated: signalWait's response will be the name of the signal that let the thread move forward, but I don't think that's really what you're looking for.

 

One way you might be able to tell if a signal is activated is by doing a signalWait on the signal with a very very low timeout (1-2 seconds?), then override the OnStepTimeout event for that step so that it doesn't fail the test/abort the test when it happens: if the step times out, then that means the signal wasn't activated; if it doesn't, then the signal was activated.

 

One warning about this way, though: this works if you're using a signalActivate, but if you're just using a signal instead (so that it only lasts for one usage), it'll consume it and stop it from being available again.  So if you're using signalActivate, this should let you do this, but probably won't if you're just using signal (although you could design it slightly more complexly to make it work with signal as well; I'm not sure if you're interested or not).

 

I've tagged this as a feature request.

 

 

Oh, and since I didn't answer that part: there's no way to kill a thread from a different thread: you have to be within the same thread to do it.

0 Likes 0 ·
spanchal avatar image spanchal koelze commented ·

Thanks Sreenath and Kevin.

 

My main objective was to be able to control threads (spawn new thread & kill existing thread ) from my main test. I had looked up the documentation and Itest step properties to see if there is a way to kill a spawned thread from main but did not find anything as Kevin righly mentioned.

 

This being the situation, I was planning to leverage signal's to kill my spawned thread.

 

Scenario:

My main test would call procedures what would run an infinte loop working on my DUT(s).  Based on a condition in my main test, i want to kill this previously spawned thread(s). So my Idea was to call signalActivate <mySignalName> first thing from my procedure before entering the while loop. Whenever, the main test wants to kill this thread, it would call signalClear <mySignalName> to clear the signal set by my procedure.  Once my procedure is in its infinte while loop, it would first check if "mySignalName" active, if so continue exercising the DUT, else "break" out of the while loop. Once the control is out of the while loop after the break, my prodecure would just close the session to the DUT and the procedure would complete, there by automatically killing the thread which was executing it.

 

main ()

{

         Call/execute my_proc in a new named thread which runs an infinte loop exercising my DUT

 

         Continue doing other stuff

         Continue doing other stuff

 

        // Based on a condition, I want to kill the previously spawned thread. To do this call the signalClear <mySignalName>

        signalClear <mySignalName>

 

}

 

my_proc()

{

      open session to the DUT

      //activate mySignalName

      signalActivate <mySignalName>

      while (1)

                 // first check if the signal <mySignalName> is Active.  If its cleared, then stop exercising the DUT and break from the while loop

 

                 if ( <mySingalName> is Active)

                           // If its Active, my main has not yet cleared it so I can exercise my DUT.

                           Invoke steps that exercise my DUT

                 else

                           // My main has Cleared <mysingalName> hence stop exercising the DUT and instead break from the while loop

                           break

 

      close session to the DUT

}

 

Inorder to achieve this, I required a way to check if a Singal was Active. So I posted the question.

 

Going with this limitation and the scenario described above,  is there any other solution/approcah to achive what I am trying to do ? If so, please suggest.

 

I will look into the work-around which Kevin suggested by using the OnStepTimeout and see it it works.  However, if iTest had the capablity to allow user to directly kill a named thread then it would ahve been a very simple implementation without any signalling involved.  BTW, thanks Kevin for suggesting the work-around and for tagging this "check if signal is active" as a feature request. 

 

Thanks,

spanchal

0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.