Thread getting stuck\hang

[Iranna Mathapati]

Hi Dennis,

Two threads(_st and _dy targets) sharing the same user define function at
the same  time...This is the reason for hang/stuck?

in both the thread ,we are calling same user define function
(itgen_explorer.startTrafficFlows) and greping the values from return
function ,using it in main function.

script was hang after completion of the program only .



On Fri, Apr 28, 2017 at 2:42 PM, Iranna Mathapati <iranna.gani28 at gmail.com>
wrote:

> Hi Dennis,
>
> Two threads(_st and _dy targets) sharing the same user define function at
> the same  time...This is the reason for hang/stuck?
>
> in both the thread ,we are calling same user define function
> (itgen_explorer.startTrafficFlows) and greping the values from return
> function ,using it in main function.
>
>
> On Fri, Apr 28, 2017 at 5:06 AM, Dennis Lee Bieber <wlfraed at ix.netcom.com>
> wrote:
>
>> On Thu, 27 Apr 2017 22:16:06 +0530, Iranna Mathapati
>> <iranna.gani28 at gmail.com> declaimed the following:
>>
>> >Hi Dennis,
>> >
>> >all function arguments declare as global and pass it to the function.
>> >
>> >All three thread is completed the execution part and after completion of
>> >execution its stuck/hang the programme.
>> >
>> >*def
>> >validate_traffic_stats_st(FT_item,RT_item,forward_path_list
>> ,return_path_list,nat_type_list,pkt_st)*
>> >:
>> >    global flag1
>> >    flag1 = 1
>> >
>>         Dangerous usage... Threads should not rely on writing to globals
>> unless
>> they surround all accesses to the global with a mutual exclusion lock --
>> OR
>> there is only one thread allowed to ever write to the global (a common
>> usage is for the main program to set a flag that signals threads to exit,
>> and the threads periodically read the flag to see if it has been set).
>>
>>
>>         <SNIP>
>> >            log.error('{0} forward path itgen verification
>> >failed'.format(nat_type))
>> >            flag1 = 0
>> >            return flag1
>>
>>         threads do not "return" data, they just exit
>>
>>         <SNIP>
>> >    return
>> >flag1,count_st_Rx,count_st_in_Rx,count_st_out_Rx,count_st_
>> Tx,count_st_in_Tx,count_st_out_Tx
>> >
>>
>>         Ditto -- all those items specified in the return are just being
>> dumped
>> on the floor.
>>
>>
>>         Recommendations: GET RID OF ALL GLOBAL VARIABLES. If you MUST have
>> shared global variables, you MUST surround access to the variables with
>> mutual exclusion locks -- otherwise you run the risk of counters and lists
>> getting out of sync. I'd also suggest compressing sharing down to single
>> objects, not half a dozen ad-hoc names. That is:
>>
>> class St_Record(object):
>>         def __init__(self):
>>                 self.flag1 = True
>>                 self.count_st_Rx = 0
>>                 self.count_st_in_Rx = 0
>>                 self.count_st_out_Rx = 0
>>                 self.whatever = suitableInitValue
>>
>>                 etc. for any other item needed for "st"
>>
>>         Do a similar class for the "dy"
>>
>>
>>         Instanciate one instance of each
>>
>> st_rec = St_Record()
>> ...
>>
>>         And inside the relevant threads simply access as
>>
>>                 st_rec.count_st_Rx += ...
>>
>> Assuming these are only used by one thread (and the main program after
>> they
>> end) you don't even need to declare them global. Python will find the
>> instances at the module level, and one can mutate the instance (ie; the
>> contents) without needing to declare global.
>>
>>
>>         "Lockup" of the program implies dead-lock, which usually means
>> race
>> conditions for the references to data objects between threads, or improper
>> use of mutual exclusion.
>> --
>>         Wulfraed                 Dennis Lee Bieber         AF6VN
>>     wlfraed at ix.netcom.com    HTTP://wlfraed.home.netcom.com/
>>
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>