Thanks to [...] Charles for asking good questions.
I second that! Thanks a lot Charles for being the voice of us C++ guys. I must admit that I often feel left-out as a C++ developer (ie: the cool new features added to VB.Net, the lack of refactorings of C++ in VS2005, the modeling features of some VS editions,
One interesting interview would be to ask some MS Games gurus and see what they have to say about game development (ie: big, AAA titles) and managed/C# code.
Is it feasible to use managed code in such a way that a game reaches the performance required to match, say, Half-Life?
It would be easy to say no outright, but if some clever people got together, I'm willing to bet something great could be done. Maybe games would take less time to build as there would be less bugs? Maybe?
1) I missed a fundamental idea I think. It sound as if the last writer wins. So if I have an atomic block, I can make changes to state. But another thread can write to the state and commit, but the first atomic block will then rollback. What did I
Your understanding sounds on par with mine, except that I don't see why the thread that commits its data wins and the other looses (except for the performance penalty).
If thread A tries to withdraw $100 from an account but there's no money in it, it retries which in effect puts it to sleep.
Then thread B comes along and credits $100 to the same account. Since no other threads are accessing that account, thread B can commit and continue its processing.
Then thread A wakes up since it detects a write to the account's memory and then retries the whole transaction which succeeds since the money is there.
Of course the thread that got into the retry state hits an additional performance penalty, but I think the whole idea of this system is to make things easier, not faster.
That sounds extremely powerful.
When you said the last writer wins, were you talking about performance?
3) How does long running I/O and DB transactions play with this. So in a normal app, I would need both to be atomic. I need the in-memory objects to be atomic and the DB to be atomic in a single transaction. How does this work?
Yeah, there's still a lot of things that are still unknown.
In the debit/credit example, what if the money never gets deposited in the account? Does an atomic transaction has a timeout value? What if an atomic block triggers an external process of some kind by setting a property of an object?
I suppose there's a whole set of guidelines and restrictions we'd have to follow when using atomic blocks. Reading the papers available would surely answer most of the unknowns.
Another great one Charles. This is some pretty complex stuff to wrap your head around, and the bit about the garbage collector and all that's required to implement atomic transactions really went way over my head!
But I tell you, I wish I had this technology in the languages I use (C++ and Pascal) RIGHT NOW!
And Haskell is really getting some air time these days
Why doesn't the Tech evangelist guy let the crypto guys answer the questions themselves. I think he is annoying.
I agree with you. He should really get his act together and give the mike, so to speak, to the person(s) he is interviewing instead of always laughing and making jokes.
I stopped downloading any video made by Scobble some time ago and I thought I'd try this one since crypto is something I'm very interested in. Very infuriating when you have interesting guests that can't answer for themselves.