[Tutor] Changing instance attributes in different threads

[Bernard Lebel]

Hi Kent,

To answer your first concern, not all changes need to be intercepted
by one the child thread. I have not given out all the details about
the program, but if the parent thread gets certain values from the
database, it will take actions that may affect the child thread other
than just by setting the localjobstatus attribute.

As for your last comments, well, the conclusion I draw is that in fact
I should not take any chance with that, and implement some thread
safety using Queue or thread conditions. I'll check that out.



Thanks for all the help!
Bernard


On 2/7/06, Kent Johnson <kent37 at tds.net> wrote:
> Bernard Lebel wrote:
> > Hi Kent,
> >
> > I have put together a little script to give a rough idea about what
> > the program does.
> >
> > http://www.bernardlebel.com/scripts/nonxsi/help/bl_threadtest.py
>
> In this code, there is no guarantee that callMeWhenAttributeChanged()
> will see every change to oBernard.firstname. It could change more than
> once while checkFirstName() is sleeping and looping. The change to
> oBernard.firstname in main could stomp on a change from
> changeAttribute() before it is seen in checkFirstName().
>
> I don't know what the consequences of missing a change are. If the names
> are some kind of command token I would use a Queue - in this example you
> have two producers and one consumer, a Queue will ensure that every
> command is seen. If there is no consequence of missing a change you
> could leave it as-is or use a threading.Condition to replace the polling
> loop with wait() / notify().
> >
> >
> > The true program does this:
> >
> > - the top program file imports a module called fcJob
> >
> > - the top program instantiate the only class in the fcJob module. The
> > class is named fcJob as well, the instance is named simply "job". This
> > instance has few attribute, the one that I'm interested in now is
> > "localjobstatus".
> >
> > - the top program file enters a while loop where it checks a variety
> > of things, and if certain conditions are met, will start a big
> > function in a separate thread.
> >
> > - the function that runs in the separate thread reads and writes the
> > localjobstatus attributes.
> >
> > - while the child thread is running, the main thread checks a database
> > every 5 seconds to test the value of certain fields.
> >
> > - would the value of specific field changed to certain values, the top
> > thread will set the localjobstatus value to something like "killed".
> >
> > - the child thread, also running a while loop, tests the local job
> > attribute at 3 times during a single iteration. If it gets a "Killed"
> > value, it will call a function that basically terminates this child
> > thread in a clean way. Ultimately, it will set the localjobstatus to
> > "Pending".
>
> This sounds unsafe. What happens if the "Pending" value is overwritten
> by another "Killed" value? It might be fine if you use two different
> status variables.
>
> When working with threads you have to imagine what would happen if one
> thread stopped indefinitely at any point, and another thread ran long
> enough to do something unexpected. Or two threads interleave statements
> in the worst possible way. Your code seems to have several opportunities
> for bad things to happen. I can't tell what the consequences of them
> are, which will determine how hard you should work to prevent them.
>
> HTH
> Kent
>
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
>