On Feb 26, 12:42 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > On Feb 26, 12:37 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote: > >> [EMAIL PROTECTED] wrote: > >>> On Feb 26, 12:04 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote: > >>>> [EMAIL PROTECTED] wrote: > >>>>> On Feb 26, 11:37 am, Jeff Schwab <[EMAIL PROTECTED]> wrote: > >>>>>> [EMAIL PROTECTED] wrote: > >>>>>>> On Feb 26, 10:59 am, Preston Landers <[EMAIL PROTECTED]> wrote: > >>>>>>>> On Feb 26, 1:45 am, [EMAIL PROTECTED] 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? -- http://mail.python.org/mailman/listinfo/python-list
