is there enough information?

castironpi at gmail.com castironpi at gmail.com
Tue Feb 26 13:56:08 EST 2008


On Feb 26, 12:42 pm, Jeff Schwab <j... at schwabcenter.com> wrote:
> castiro... at gmail.com wrote:
> > On Feb 26, 12:37 pm, Jeff Schwab <j... at schwabcenter.com> wrote:
> >> castiro... at gmail.com wrote:
> >>> On Feb 26, 12:04 pm, Jeff Schwab <j... at schwabcenter.com> wrote:
> >>>> castiro... at gmail.com wrote:
> >>>>> On Feb 26, 11:37 am, Jeff Schwab <j... at schwabcenter.com> wrote:
> >>>>>> castiro... at gmail.com wrote:
> >>>>>>> On Feb 26, 10:59 am, Preston  Landers <pland... at gmail.com> wrote:
> >>>>>>>> On Feb 26, 1:45 am, castiro... at gmail.com wrote:
> >>>>>>>>> Two options occurred to me, which the first showed up in the earlier
> >>>>>>>>> extremely skeletal and cryptic post:
> >>>>>>>> Perhaps you would be more likely to get the kind of help you seem to
> >>>>>>>> want
> >>>>>>>> if you refrained from posting "cryptic and skeletal" messages. The
> >>>>>>>> fact that many
> >>>>>>>> other people have pointed this out to you as of late would tend to
> >>>>>>>> suggest
> >>>>>>>> you are trolling, i.e. intentionally trying to foster miscommunication
> >>>>>>>> and threads
> >>>>>>>> that do nothing to advance anyones understanding.
> >>>>>>>> And regarding your other recent post about trying to find a "solution"
> >>>>>>>> to the "problem"
> >>>>>>>> of immutable types...  Due to the above reasons you are unlikely to
> >>>>>>>> influence the
> >>>>>>>> design of the core language with half-baked stream of consciousness
> >>>>>>>> ramblings. These
> >>>>>>>> belong in your LiveJournal, not in c.l.python.
> >>>>>>>> If you have a problem you need help with, please read this entire
> >>>>>>>> document about 3 times
> >>>>>>>> before posting anything else:
> >>>>>>>>http://catb.org/~esr/faqs/smart-questions.html
> >>>>>>>> Specifically this:
> >>>>>>>>http://catb.org/~esr/faqs/smart-questions.html#beprecise
> >>>>>>>> and this:
> >>>>>>>>http://catb.org/~esr/faqs/smart-questions.html#goal
> >>>>>>> Ugh, very well.  You call for an explanation.
> >>>>>>> Back home, the original post would be interesting, so I wrote it.
> >>>>>>> Whatever reactions other people have to them is information that is
> >>>>>>> unavailable to me.  I don't know you.  I'm rather irked by a
> >>>>>>> proportion of posts, but for my part, it's hard to get me to point a
> >>>>>>> finger.
> >>>>>>> I am not a troll.  I want a sustainable, healthy, productive,
> >>>>>>> educational, informative relationship with frequenters of c.l.p, the
> >>>>>>> Python community at large, and anyone who has anything non-negative to
> >>>>>>> contribute.  If you are wanting to see how I react to hostility, just
> >>>>>>> ask.  I'll fake it for you, but only for a second at a time.
> >>>>>> Wow.  I sure hope I don't come across like castiron does here.
> >>>>>>> Now, what help is it that you believe I seem to want?  All I asked for
> >>>>>>> was, ideas.
> >>>>>> It's a little difficult for me to interpret your code, partly because I
> >>>>>> am nbt very familiar with Python's support for concurrency.  But what
> >>>>>> are you trying to a achieve?
> >>>>>> You mentioned:  "I recently ran into a case (* would that be helpful to
> >>>>>> describe here?) where thread1 had to do something, thread2 had to do
> >>>>>> something after that, and thread1 had to wait for that, then do
> >>>>>> something else, and thread2 again had to wait before starting the first
> >>>>>> thing again."
> >>>>>> This is ordinarily called a Producer-Consumer model.  It is often
> >>>>>> implemented using semaphores.  Googling "python semaphore" turns up this
> >>>>>> documentation:
> >>>>>>http://www.python.org/doc/lib/semaphore-objects.html
> >>>>>> That page, in turn, links to an example of the proper use of semaphores
> >>>>>> in Python.  Does that help?- Hide quoted text -
> >>>>>> - Show quoted text -
> >>>>> Hi Jeff.  I've enjoyed your recent posts.
> >>>>> I'm not quite sure a semaphore is exactly the synchronization object
> >>>>> I'm looking for, but I'm a little new to concurrency myself.
> >>>>> In the interface I design, only one with-call can get the result at
> >>>>> once.  It was my understanding that semaphores, and many other synch.
> >>>>> objs. returned control at random.
> >>>> I take this to mean that your interface offers a function returns
> >>>> immediately, rather than waiting for the work to complete.  Is that correct?
> >>>>> In fact, in the background, I'm working on something a little more
> >>>>> substantial than this, but it's not done, so the only review of it I
> >>>>> can perform is of its interface.
> >>>> The interface is (in my opinion) usually the best place to start the
> >>>> code, anyway.
> >>>>> If someone has a "yes, but in half the lines, at twice the speed,"
> >>>>> then tear my posts to shreds.
> >>>> It is not quite clear what your code is intended to do.  That doesn't
> >>>> mean there's necessarily anything wrong with it, but it's hard for most
> >>>> Usenetters to take the time to read such long sequences of code.  Would
> >>>> it be possible for you to post a complete program, that we can actually
> >>>> run?  Wherever your code is not yet ready, just put a line or two of
> >>>> "stub" code, and add a comment to explain what should be happening.- Hide quoted text -
> >>>> - Show quoted text -
> >>> Sure.  And honestly, I have no idea what the best way to go about this
> >>> is, except keep trying.
> >>> th1       th2
> >>> set cmd
> >>>           run cmd
> >>> get result
> >>>           acknowledge
> >>> continue  continue
> >>> th2 won't -run cmd- until th1 completes -set cmd-.  th1 won't -get
> >>> result- until th2 completes -run cmd-.  and once -acknowledge-
> >>> completes, both can go about their merry ways.
> >> That is exactly the kind of case where semaphores are usually used.
> >> Thread1 can "fill" the semaphore when the command is ready, then Thread2
> >> can "empty" the semaphore once it has finished running the command.
>
> >>> In the example last
> >>> night, th2 continued to loop to handle requests in a collection of
> >>> threads, but th1 had pressing business elsewhere.
> >> No problem.  It should be waiting on a semaphore, though, not just
> >> "hot-looping."  (I am amused by the idea of a thread having pressing
> >> business elsewhere.)
>
> >>> Dated 05:07 PST, the code should be runnable.  But the only thing is,
> >>> I developed it in Python 3.0a2.  In particular, line 71 def
> >>> thloop( thd ), and line 82 def op100( thd ), should demonstrate that
> >>> interface.
> >> Sorry, I am still having some trouble following it.  :-(  Maybe somebody
> >> else here is also trying 3.0 already.- Hide quoted text -
>
> >> - Show quoted text -
>
> > The relevant snippet is:
>
> > def thloop( thd ):
> >     while thd.cont:
> >         with thd.step[1]:
> >             if not thd.cont: break
> >             print( 'step 1', end= ' ' )
> >             thd.ret= thd.cmd+ 1
> >         with thd.step[3]:
> >             print( 'step 3' )
> >             thd.ret= None
> >         thd.step.complete()
>
> > def op100( thd ):
> >     with thd.step[0]:
> >         print( 'step 0', end= ' ' )
> >         thd.cmd= 100
> >     with thd.step[2]:
> >         print( 'step 2', end= ' ' )
> >         ret1= thd.ret
> >     assert ret1== 101
>
> > I don't see how semaphores could prevent thd.step[2] and thd.step[1]
> > from taking turns in the wrong order.  Polling is bad.
>
> I'll try to take a closer look at this a little later.  It will be a
> good chance to learn Python's semaphore interface.  However, I am
> getting the feeling you may have to solve this one on your own. :(- Hide quoted text -
>
> - Show quoted text -

I want to awaken -that- -specific- -thread-.

Semaphore acquire: "The implementation may pick one at random."
Lock acquire: "which one of the waiting threads proceeds is not
defined"
Event set: "All threads waiting for it to become true are awakened"
Condition notify: "This method wakes up one of the threads waiting"
Condition notifyAll: "Wake up all threads waiting on this condition"

I will contend it's impossible without a specialization.  Certainly an
array of semaphores could fit the bill; is that what you were
suggesting?



More information about the Python-list mailing list