Is there a way to protect a piece of critical code?

[Steve Holden]

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).

> 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].

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].

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].

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].

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.

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].

If you have been, thank you for reading. If you haven't then I guess you 
won't be reading this either. Have a nice day. And a Happy New Year to 
all my readers.

regards
  Steve

[1]: It killed the cat, thereby letting MSDOS's "type" command get a 
toehold and leaving people to fight about whether "less" really was 
"more" or not.

[2]: Of course I'm joking. But it seems that Twisted's detractors don't 
have much of a sense of humour, so it's much more interesting to poke 
fun at Twisted, which at least has the merit of having been designed by 
real human beings with brains and everything. Though I have never seen 
any of them take a beer. [4].

[3] The UNIX fork() system call is actually named in honour of Edsger 
Dijkstra's discussions of the philosophers' problem, a classic text in 
the development of critical sections. Not a lot of people know that. 
Mostly because I just made it up.

[4] That's this week's dig at both the Twisted community. I cheerfully 
admit that although this assertion is true it's a simple attempt to give 
currency to a scurrilous fabrication. I'm hoping I can persuade the 
Twisted crew to descend on PyCon /en masse/, thereby multiplying the fun 
quotient by 1.43.

[5] Including thread.Lock and Queue.Queue - I bet you're getting sorry 
you asked now, aren't you?

[6] Which will be the year after 2007, which will be the year of Python 
3000. Or not, depending on whether Py3k is a dead parrot or not. I'm 
personally betting on "not". But not necessarily on 2007.
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb     http://del.icio.us/steve.holden
Blog of Note:          http://holdenweb.blogspot.com