Sig, That's an interesting view of it, but I generally see it differently. "Good" threads are independent. They do things that are either truly separate tasks, or work on something lengthy and "report back" when it is finished. Being heavily rooted in engineering mechanics and having become something of an amateur grease monkey (hopefully one who knows his limits), I often visualize threads as gears with the stack pointer as a timing mark near the edge. The critical sections come into play only when the teeth might collide. It is a flawed analogy, but keeps me grounded.
Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Igor Stasenko Sent: Wednesday, March 25, 2009 7:33 PM To: [email protected] Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today? 2009/3/26 Schwab,Wilhelm K <[email protected]>: > To call threaded code incomprehensible is to ignore many appropriate uses of > them. The presumption is that software is thrown together and then made to > work, rather than engineered to work correctly from the bottom up. Rather > than focusing to exclusion on the non-determinism of threading, the author > should also consider the independence of the individual threads; threads that > do one thing and do it well can be far simpler than code that chops lengthy > processes into small chunks that can be executed in sequence. > > At the risk of sounding prematurely curmudgeonly, I have used both approaches > over time (using slicing when threads were not available to me). I would > much rather face an over-protected (hence deadlocking) multi-threaded program > than try to sort out a single-threaded switch statement from hell that tries > to do the same job. Of course, I come at this with a Smalltalk bias, where > finding the deadlock is often as simple as following a stack trace to an > offending critical section. Dirty writes are a bear in any language, but my > general approach is "don't make that mistake." It works for me. > Been there did that.. i especially run to a problem with deadlocking, ended up with coding a classes which enforcing the right order of entering the critical sections i.e. you can't enter the critical section B, if you previously not entered into critical section A. This works, of course, but not an elegant neither scalable.. because it leads to the point where you can simply have a single global critical section to be protected from all contention cases :) > Bill > > --- > Wilhelm K. Schwab, Ph.D. > bschwab AT anest DOT ufl DOT edu > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Michael van der Gulik > Sent: Wednesday, March 25, 2009 4:39 PM > To: [email protected] > Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new > Smalltalk?project today? > > On 3/26/09, Markus Fritsche <[email protected]> wrote: >> Igor Stasenko <[email protected]> wrote: >> >>> | array sum1 sum2 | >>> sum1 := 0. sum2 := 0. >>> array := Array new: 10. >>> [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: >>> 10) ] ] fork. >>> [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: >>> 10) ] ] fork. >>> 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ]. >> >> Something I came across leately: Threads are evil - >> http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf > > They're not evil, just mischievous. > > I find it a fairly unimpressive article that recites what any decent > programmer already knows about parallel programming. > > "This scenario is bleak for computer vendors: their next generation of > machines will become widely known as the ones on which many programs crash." > > heh. True. > > Gulik. > > -- > http://gulik.pbwiki.com/ > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
