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 -- http://mail.python.org/mailman/listinfo/python-list
