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.gan...@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 <wlfr...@ix.netcom.com>
> wrote:
>
>> On Thu, 27 Apr 2017 22:16:06 +0530, Iranna Mathapati
>> <iranna.gan...@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
>> wlfr...@ix.netcom.com HTTP://wlfraed.home.netcom.com/
>>
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>
--
https://mail.python.org/mailman/listinfo/python-list
