Critical sections and mutexes

[David Brady]

> -----Original Message-----
> From: Cliff Wells
> [mailto:logiplexsoftware at earthlink.net]
> Subject: Re: Critical sections and mutexes
> 
> If this were a classroom, then I would probably
> concede at this point.  However, without the luxury
> of being able to hold someone's hand and lead
> them step-by-step, I think it's best to just give
> them the most appropriate information for solving
> their immediate problem.  

As the Newbie In Question, I'd like to chime in here
and say that (a) the help that has already been
provided has been most useful, and (b) watching this
discussion has really helped me work out some of the
finer points of the issue.

> > I think it discourages newbies to bombard them
> > with all the locking issues up front, and it's
> > a real strength of Python (especially for
> > programming newbies) that you can often "get
> > away" with no explicit thread-safety measures. 

I both agree and disagree.  To a newbie unfamiliar
with threading in the first place, yes, I can see that
bombarding them with the locking issues can be
discouraging.  In my case, however, I'm familiar with
threading, and I have found Python's locking mechanism
to be absolutely brilliant.  I knew what I wanted to
do; I just needed someone to explain the Python way of
doing it.  Once I learned that I couldn't do critical
sections, I redesigned those parts of my code that
wanted them to use shared resources instead, and I was
in business.

My take on this point is that one should always err on
the side of too much information rather than too
little.  :-)  Both sides of this discussion should
take that as a compliment, btw.  It turns out I'm
going to need a more complete locking scheme than the
GIL provides, but now I can say that because I have a
better feel for where the GIL stops and manual locking
has to start.

For example, I can predict a common type of race
condition in my class without any extra locking.  My
class looks something like this:

class PriorityQueue:
    def __init__(self):
        self.NormalQueue = Queue.Queue()
        self.PriorityQueue = Queue.Queue()
        self.IsWaiting = 0

Now, the Queue.Queue()'s are themselves threadsafe, so
I shouldn't have any collisions accessing either queue
directly.  However, I have a Push() and Pop() method
as well.  Push() puts a message on one of the queues
(depending on whether or not the priority flag is
set), and then sets the IsWaiting flag.  Pop() checks
the priority queue first, then the normal queue, and
returns one message.  If both queues are empty after
the message is popped, it sets the IsWaiting flag to
0.

If the class itself doesn't support locking, it would
be possible for one thread to drain all the queues,
and be just about to clear the IsWaiting flag, then
have another thread push a message and set IsWaiting,
and then return to the first thread who clears
IsWaiting.  We are left with a message in the queue
but nobody retrieves it until more messages arrive and
set IsWaiting again.

Again, thank you all for your comments.

-dB

=====
David Brady
daves_spam_dodging_account at yahoo.com
I'm feeling very surreal today... or *AM* I?

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com