Re: The right idiom for reading from CAPI panes
Im sorry, but I don't know how I got on this list, but can the administrator please remove me or can someone inform me on how to do it. I have used lispworks but it was for a class, and I do not use it anymore. Thank you all and I apologize for any inconvenience. ---- Original message ---- >Date: Fri, 25 Jan 2008 18:08:24 -0700 >From: David McClain <dbm@refined-audiometrics.com> >Subject: Re: The right idiom for reading from CAPI panes >To: Edi Weitz <edi@agharta.de> >Cc: lisp-hug@lispworks.com > > Whoa! Edi! > You have certainly given me a lot of stuff to chew > on... > I just had a response, from someone watching this > thread of conversation, that he has used Erlang for > such cases. I have used Erlang in the past, but I > didn't realize its kernel was fully re-entrant. But > Erlang's in-situ module update philosophy is > certainly something we are aiming for. And I think > Lisp could shine in this regard. > But your response here shows me what a remarkable > mind you have. I am impressed! > David McClain > Chief Technical Officer > Refined Audiometrics Laboratory > 4391 N. Camino Ferreo > Tucson, AZ 85750 > email: dbm@refined-audiometrics.com > phone: 1.520.390.3995 > web: http://www.refined-audiometrics.com > On Jan 25, 2008, at 17:40, Edi Weitz wrote: > > Hi David, > Thanks for your thoughts on this. Your analysis > makes it pretty > obvious that my idea about how the "big lock" is > implemented was > wrong. And your test cases also inspired me to > play around a bit > more. Here are some findings: > 1. I did all my tests on Windows, but > unsurprisingly the results were > the same as yours on OS X. > 2. In case someone here cares, AllegroCL (8.1 on > Windows) exposes the > same behaviour. You can also lock up its > IDE completely if your > threads keep the Lisp image busy. > 3. This is a machine with an Intel Core 2 Duo, > i.e. it has two cores. > As expected, with both LispWorks and > AllegroCL the CPU utilization > never went beyond 50%. > 4. I then ran the tests on a 64-bit Linux (same > hardware) using > OpenMCL. The listener there remained fully > responsive and the CPU > was at 100%. > 5. I was then reminded of the remark in the > LispWorks manuals that > while there can only be one Lisp thread at a > time there could be > other threads executing foreign code in > parallel. That obviously > means that whenever the Lisp calls into FLI > land, the OS must get > a chance to switch threads. So, I modified > your test code a > little (see attachment) to see how usage of > the FLI might affect > the results. > 6. First of all, the high optimization settings > in FOO1 are there for > a reason. If you don't have them, a call > to (TEST) will make the > IDE a bit sluggish but it won't lock it > up. My guess is that Lisp > functions usually relinquish the big lock at > their entry points, > but it seems you can optimize that away. > 7. The next (at least to me) surprising result > is that DOIT1-2 is > actually faster than DOIT1-1 - on my machine > it's approximately > 6.5 seconds vs. 8.5 seconds. I have no > explanation for this. > 8. Now for the real test: A call to (TEST) will, > as I already said, > lock up the IDE. Also, if you look at > *COUNT1* and *COUNT2* after > the test is finished, you'll see that either > one of the threads > didn't run at all or that they both managed > to finish completely > without being killed. This is equivalent > to your original code. > A call to (TEST :FLI T) OTOH will /not/ lock > up the IDE. > Specifically, you can investigate the > counters while the test is > running and you'll see that both threads are > progressing. So, > even with this "simulated FLI call" the big > lock loses its power. > 9. The priority setting doesn't seem to make a > big difference for > these tests. > 10. Now look at the value of *FOO* after (TEST > :FLI T) has finished. > It is not what one would expect it to be if > there were some kind > of atomicity guarantee for the SETQ form. > I think this shows what > you'll have to deal with once you're working > with a real > SMP-capable Lisp. > Let me finally drive this long-winded message back > home to my original > topic. Do you remember my toy example with the > A1-A2-A3-... and > B1-B2-B3-... sequences? Now, as LispWorks must > call into the native > windowing system in both cases (A and B), there's > certainly some FLI > machinery involved. So, it isn't completely > unthinkable that there > actually /are/ thread switches within these > sequences. Most likely > there won't be enough back and forth for the > invalid return value to > really show up, but I wouldn't be 100% sure that > reading from CAPI > objects from the wrong thread is always totally > safe. > OK, that's it for now. Any comments? > Cheers, > Edi. > PS: Maybe I /do/ have an explanation for #7 above > (or maybe this is > just nonsense). I could imagine some kind > of "thread congestion" > going on there - the OS is trying to give > time slices to other > Lisp threads (the IDE has some), but they > always immediately > return because DOIT1-1 doesn't give up the > big lock. This results > in the DOIT1-1 thread having an unfair share > of the execution time > alloted to the whole process and thus > increases the pressure on > the OS to try even harder to switch to other > threads. In other > words, the time difference one can observe > is mostly owed to > "failed" attempts to switch threads and it's > not time spent in the > Lisp loops. Does that make sense? > <foo2.lisp>