Unofficial wish list status.(Jul 2008)

[superdan]

Me Here Wrote:

> superdan wrote:
> 
> > Oskar Linde Wrote:
> > 
> > > superdan wrote:
> > > > Me Here Wrote:
> > > > 
> > > >> Walter Bright wrote:
> > > > > 
> > > >>> Yes, but the onus will be on you (the programmer) to prevent data races
> > > and >>> do proper synchronization.   
> > > >> In the scenario described, the main thread initialises the array of
> > > data. Then, >> non-overlapping slices of that are tioned out to N worker
> > > threads. Only one >> thread ever modifies any given segment. When the
> > > worker threads are complete, >> the 'results' are left in the original
> > > array available in its entirety only to >> the main thread.
> > > > > 
> > > >>> You have to be very wary of cache effects when
> > > >>> writing data in one thread and expecting to see it in another.
> > > >> Are you saying that there is some combination of OS and/or hardware L1/L2
> > > >> caching that would allow one thread to read a memory location
> > > (previously) >> modified by another thread, and see 'old data'?
> > > > > 
> > > >> Cos if you are, its a deeply serious bug that if its not already very
> > > well >> documented by the OS writer or hardware manufacturers, then here's
> > > your chance >> to get slashdotted (and diggited and redited etc. all
> > > concurrently) as the >> discoveerer of a fatel processor flaw.
> > > > 
> > > > google for "relaxed memory consistency model" or "memory barriers". geez.
> > > 
> > > I presume the discussion regards symmetric multiprocessing (SMP).
> > > 
> > > Cache coherency is a very important element of any SMP design. It 
> > > basically means that caches should be fully transparent, i.e. the 
> > > behavior should not change by the addition or removal of caches.
> > 
> > you are perfectly correct... as of ten years ago. you are right in that cache
> > coherency protocols ensure the memory model is respected regardless of adding
> > or eliminating caches. (i should know coz i implemented a couple for a
> > simulator.) the problem is that the memory model has been aggressively
> > changed recently towards providing less and less implied ordering and
> > requiring programs to write explicit synchronization directives.
> > 
> > > So the above scenario should never occur. If thread A writes something 
> > > prior to thread B reading it, B should never get the old value.
> > 
> > yeah the problem is it's hard to define what "prior" means.
> > 
> > > "Memory barriers" have nothing to do with cache consistency. A memory 
> > > barrier only prevents a single CPU thread from reordering load/store 
> > > instructions across that specific barrier.
> > 
> > memory barriers strengthen the relaxed memory model that was pushed
> > aggressively by the need for faster caches.
> 
> Since in the scenario I describe, Each thread or cpu is dealing with a single
> section of memory. And each section of memory is being dealt with by a single
> thread or cpu, the is effectively no shared state whilst the threads run, Hence
> no possibility of cache inconsistancy due to pipeline reordering. Ie.

goodness this is so wrong i don't know where to start from. like trying to figure out what's bad about a movie that's real real bad. you have no idea what you're talking about do you. just throwing terms here and there and making unstated assumptions that worked in 1980 on an atari.

first off there is word tearing. u can't change one character in a string willy-nilly. the rest will need to be masked and you got a race condition right there. but of course you had no idea.

> main thread populates a[ 0 .. 1000 ];
> 
> for thread 1 .. 10
>     spawn( thread, \a[ ((thread-1 ) *100 ) .. ((thread-1 + 100) * 100 ] );
> 
> main thread waits for all threads to terminate;
> 
> main thread does something with a[];
> 
> In any case, cache consistancy issues due to pipeline reordering do not survive
> context switches, so the issue is a non-issue for the purposes of the
> discussion at hand. Ie. threading
> 
> Pipelines cover single digit or low double digit runs of non-branching
> instructsion at most. A context switch consists of hundreds if not thousands of
> instructions on all but the most highly tuned of real-time kernels. This is a
> very localised issue, for the compiler writer, not the application programmer
> to worry about.

this is just babble. you bring pipelines and thread switching because you have no idea what the discussion is about and you try to relate it to the little things 1985 vintage you have a vague idea about. in the name of brian: we got more than one processor today. wake up and smell the shit.

> I know Walter *is* a compiler writer, but this is a complete red-herring in the
> context of this discussion.

i'll tell you what's a red herring: everything you say. your knowledge is obsolete by decades. you have no idea what you are talking about yet you try to defraud us by using cockiness. you even have the nerve to criticize walter and andre. tell you what. walter's brown underwear and andreis dirty socks with holes in'em know more shit than you. i'll leave it to sean to serve you your arrogant ass on a silver plate.