Is there a way to protect a piece of critical code?
Hendrik van Rooyen
mail at microcorp.co.za
Thu Jan 11 01:17:07 EST 2007
"Steve Holden" <steve at holdenweb.com> wrote:
> Hendrik van Rooyen wrote:
> > Hi,
> >
> > I would like to do the following as one atomic operation:
> >
> > 1) Append an item to a list
> > 2) Set a Boolean indicator
> >
> > It would be almost like getting and holding the GIL,
> > to prevent a thread swap out between the two operations.
> > - sort of the inverted function than for which the GIL
> > seems to be used, which looks like "let go", get control
> > back via return from blocking I/O, and then "re - acquire"
> >
> > Is this "reversed" usage possible?
> > Is there some way to prevent thread swapping?
> >
> This seems to me to be a typical example of putting the cart before the
> horse. Therefore, please don't think that what follows is directed
> specifically at you: it's directed at everybody who thinks that their
> problem is something other than it really is (of course, my extensive
> experience on c.l.py plus my well-known psychic powers uniquely qualify
> me to explain to you that you don't understand your own problem).
Yes of course - I see this happening all the time here
- have probably done it myself...
>
> > The question arises in the context of a multi threaded
> > environment where the list is used as a single producer,
> > single consumer queue - I can solve my problem in various
> > ways, of which this is one, and I am curious as to if it is
> > possible to prevent a thread swap from inside the thread.
> >
> Of course you will know what they say about curiosity [1].
>
My understanding about it is not as advanced as yours-
I was under the possibly false impression that it had
something vaguely to do with felines.
> You don't say what the Boolean indicator is for. My natural inclination
> is to assume it's to say whether there's anything in the list. The
> Twisted crew can tell you this is a terrible mistake,. What you should
> really do is define a function that waits until there is something to
> put on the list and then returns a deferred that will eventually
> indicate whether the insertion was successful [2].
>
How did you ever guess that it was exactly what I in my
misguided zeal to make the code understandable for myself did?
As for the Theatrical Twisted way of saying:
"Don't call us, we'll call you ! "
I don't reeaally have the time to wait...
> But your *actual* problem appears to be the introduction of critical
> sections into your program, a question about which computer scientists
> have written for over forty years now, albeit in the guise of
> discussions about how to get a good meal [3].
>
Hmmmm - this can get philosophical - Most days, I write in assembler,
on bare metal small systems - and would ya believe - no matter how
I squirm - some bloody piece of code always turns out to be
critical - the hard part is to recognise that it is so when you write it,
Instead of having it bite you in the arse whan you are not looking.
> I could go on, but I am realising as I write that less and less of this
> is really relevant to you. In short, please don't try to reinvent the
> wheel when there are wheelwrights all around and a shop selling spare
> wheels just around the corner. Python is already replete with ways to
> implement critical sections and thread-safe queuing mechanisms [5].
>
Now I know that a Youngster like you would not believe me when I tell
you that I know about queues and locks, so I won't bother.
> I could, of course, say
>
> http://www.justfuckinggoogleit.com/search.pl?query=python+atomic+operation
>
> but that would seem rude, which is against the tradition of c.l.py.
> Besides which the answers aren't necessarily as helpful as what's been
> posted on this thread, so I'll content myself with saying that one's can
> often be better spent R'ing TFM than posting on this newsgroup, but that
> while Google /may/ be your friend it's not as good a friend as this
> newsgroup.
>
Rudeness is against the tradition?
But bluntness is ok?
> If it isn't obvious that this post was meant more to amuse regular
> readers than inform and/or chastise someone who isn't (yet) one then
> please accept my apologies. Fortunately I don't normally go on like this
> more than once a year, so now it's hey ho for 2008 [6].
>
Happy New Year Steve - I for one have missed your posts lately.
I was beginning to feel you don't love me anymore...
8<-------------- some explanatory stuff ------------------
*sigh* - I guess all this is just a nice way of saying "no!" to the
question.
- Hendrik
More information about the Python-list
mailing list