Re^4: Why it is important to counter FUD.

You serve nobody with overdone modesty.

It is neither modesty, nor overdone, that causes me to decline to rise to Limbic~Region's challenge.

In 1907, a guy called Ernest Rutherford proposed a view of the newly postulated atoms, that won him a Nobel prize, caused him to be ennobled, and more than thirty years later caused me to get a mention in the end-of-year role of distinction in my mediocre secondary school (11..16y/o).

A lesser known fact is that he knew that his 'sticky balls' model was flawed long before he was honoured. He even attempted to dissuade those honouring him from doing so on the basis of his 1907 papers. To no avail, as testified by the fact that my work some 30 years after his death, based upon the received wisdom at that latter time as perpetuated in the reference books and curriculum from which I was taught; was wrong. Utterly, and completely; fundamentally, emphatically and hopelessly; wrong. And he knew it. And he tried to tell everyone.

And yet, more that 60 years after his original paper; more than 30 years after his death; and 50 years after he published his proof that his original ideas were wrong; they remained 'received wisdom'.

My point?

When Einstein first published his theories, he was ridiculed. And yet those theories underlie so much of what we now take for granted. Eg. SatNav. But equally, he hated quantum mechanics. The theory, the math, and the consequences. And yet, there is much fundamental research, huge economic investment, and even demonstrable, practical product that is explained only by QM.

I am intimately, and vocally, aware of the limitations of the current implementation of the iThreads model. I am also aware that many of the problems they are mooted to solve can be solved, or solutions approximated, without them. But at what cost?

So, whilst if anyone has a clear, complete and concise description of a problem they (think they) need to solve through threading, I am usually able to either supply code that achieves that, or direct them to an alternative that might be superior. Or both.

Attempting to provide a single template for all threading solutions; or a set of patterns applicable to a range of programming problems, is beyond my capabilities. I am both aware of my knowledge of threading; and the limitations of both the implementation and that knowledge.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^4: Why it is important to counter FUD.

Replies are listed 'Best First'.
Re^5: Why it is important to counter FUD. by ELISHEVA (Prior) on Jan 03, 2011 at 11:08 UTC
If you are concieving of a tutorial as the "Unified Field Theory" of threading, you have a point. However, you have a great deal of accumulated knowledge spread out across many nodes and depths of reply. I think it would be helpful to many if you would gather than knowledge together and present it in a single read through document. Call it "A field guide to some common threading problems" if you wish. Fill the introduction with a disclaimer about what the essay does not discuss. Include the essay above, if you think it would help. I think the benefit would be in having a one-stop shopping location for BrowserUK's insights and years of experience, not in having the final "perfect" and "correct" exposition of all threading issues known to human kind.	[reply]
Re^6: Why it is important to counter FUD. by BrowserUk (Patriarch) on Jan 03, 2011 at 12:18 UTC
Oh dear. I guess my analogy was too big and too abstract. My point was simply that knowledge evolves. All perl programs are threaded; and starting a second or subsequent thread is trivial. The devil is in the ITC. Beyond simply listing the already well known mechanisms, there is generically, little more to be said beyond what is already in the documentation. Picking the right mechanism depends entirely upon the specific of each application. And any single application might conceivably require the use of all ITC mechanisms. Picking the "right" implementation for each piece of communication likewise. It doesn't make sense to use a queue to share the state of a single value. It doesn't make sense to use a shared scalar to share a stream of values. As for the one stop shop: This is as good a summary of those 3000 posts as I can come up with. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]