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