Is there a way to protect a piece of critical code?
steve at holdenweb.com
Wed Jan 10 19:26:24 CET 2007
Hendrik van Rooyen wrote:
> 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 .
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 .
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 .
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 .
I could, of course, say
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
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 .
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.
: 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.
: 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. .
 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.
 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.
 Including thread.Lock and Queue.Queue - I bet you're getting sorry
you asked now, aren't you?
 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
More information about the Python-list