Thread getting stuck\hang

Iranna Mathapati iranna.gani28 at gmail.com
Fri Apr 28 05:12:33 EDT 2017


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
>


More information about the Python-list mailing list