Re^7: Sharing large data structures between threads

Actually, it converts the asynchronous commands from the threads or forks into a single synchronous stream. This mimicks an early IBM-mainframe style solution to transaction processing from way back.

With all the inherent problems of those early attempts to deal with this problem.

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.

And that cycle consists of each thread doing some trivial amount of processing before blocking on the shared resource and then having to wait several context switches for all the other TOEs to have their chance. The net result is that throughput slows to a crawl.

The modern incarnation of the idea, Software Transactional Memory, avoids some of the problems of the older manifestations by using very optimistic operations. That is, instead of waiting on a lock before going forward with operations, they go ahead on the assumption that it's okay, and then check after to see if it was; and redo the operation if it wasn't.

However, despite the the big guns in concurrency research-- Edinburgh, Brown et al.--having done a huge amount of intensive research on STM in the past few years, I'm unaware of any practical implementations outside of the pure functional languages. And even there, there is good evidence that for generic real-world workloads, thread starvation--individual threads that make no progress--is a frequent problem with no solution. And that well crafted lock-free solutions beat STM for performance, throughput and fairness.

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^7: Sharing large data structures between threads

Replies are listed 'Best First'.
Re^8: Sharing large data structures between threads by anonymized user 468275 (Curate) on Apr 21, 2011 at 09:59 UTC
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	[reply]
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]