Re^8: Sharing large data structures between threads

re "The basic problem with serialising commands from asynchronous threads of executions (TOE), is that they frequently, very rapidly descend into lock-step. This where all the threads bar one end up waiting for the current thread to complete. And when it does, then next gets to do one thing, then the next. And before the queue is played out, the original thread has joined the end and you are into a cycle."

Either you are describing some specific experience of your own involving a retry loop combined with serialisation or are just imagining something incorrectly, but either way there is absolutely no justification for your attributing the behaviour you describe to the functionality I proposed. Come on, do you think IBM transaction monitors would have survived on the market for years if this were true?

One world, one people

Comment on Re^8: Sharing large data structures between threads

Replies are listed 'Best First'.
Re^9: Sharing large data structures between threads by BrowserUk (Patriarch) on Apr 21, 2011 at 13:01 UTC
or are just imagining something incorrectly, You do not have to take my word for it. Read the literature. As a starting point, read this paragraph that talks of "no longer have[ing] the synchronous "lockstep" execution of Chapter 4". Then go back and read Chapter 4 in its entirety and see if it doesn't fit more or less exactly with your proposed "converts the asynchronous commands from the threads or forks into a single synchronous stream"? And consider that your half-remembered, half-understandings of things that you encountered 20 years ago, are probably less reliable than things I read in detail about last month or last year or the year before. do you think IBM transaction monitors would have survived on the market for years if this were true? Firstly, the requirements of a pseudo-concurrent virtual machine time-sharing system running on 70s/80s single core hardware with clock speeds in the low 10s of megahertz are quite different to those of true shared-state concurrency of today's multi-threaded, multi-core hardware running at 2 or 3 gigahertz. IBM know this and moved on long ago. If you need more explanation of that, again, read the literature. Secondly, the single biggest killer of performance in concurrent systems, shared-state or otherwise, is synchronisation. Full stop. It's an indisputable, very well documented fact known by anyone who has read anything relevant in the past 10 years or more. To achieve best (or even good) performance on concurrent systems, you must avoid synchronisation like it was the plague. To base your inter-TOE communications mechanism around the sole concept of "converts the asynchronous commands from the threads or forks into a single synchronous stream" is disastrous. You have effectively created a single linear flow program, except you've thrown a significantly costly context switch between each step of your serialised stream. Don't take my word for it, but don't make it up as you go along. Read the literature. It is out there. 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]

Replies are listed 'Best First'.

Re^9: Sharing large data structures between threads
by BrowserUk (Patriarch) on Apr 21, 2011 at 13:01 UTC

or are just imagining something incorrectly,

You do not have to take my word for it. Read the literature.

As a starting point, read this paragraph that talks of "no longer have[ing] the synchronous "lockstep" execution of Chapter 4". Then go back and read Chapter 4 in its entirety and see if it doesn't fit more or less exactly with your proposed "converts the asynchronous commands from the threads or forks into a single synchronous stream"?

And consider that your half-remembered, half-understandings of things that you encountered 20 years ago, are probably less reliable than things I read in detail about last month or last year or the year before.

do you think IBM transaction monitors would have survived on the market for years if this were true?

Firstly, the requirements of a pseudo-concurrent virtual machine time-sharing system running on 70s/80s single core hardware with clock speeds in the low 10s of megahertz are quite different to those of true shared-state concurrency of today's multi-threaded, multi-core hardware running at 2 or 3 gigahertz. IBM know this and moved on long ago. If you need more explanation of that, again, read the literature.

Secondly, the single biggest killer of performance in concurrent systems, shared-state or otherwise, is synchronisation. Full stop. It's an indisputable, very well documented fact known by anyone who has read anything relevant in the past 10 years or more. To achieve best (or even good) performance on concurrent systems, you must avoid synchronisation like it was the plague.

To base your inter-TOE communications mechanism around the sole concept of "converts the asynchronous commands from the threads or forks into a single synchronous stream" is disastrous. You have effectively created a single linear flow program, except you've thrown a significantly costly context switch between each step of your serialised stream.

Don't take my word for it, but don't make it up as you go along. Read the literature. It is out there.

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]