posted by evildictaitor

posted by Charles

posted by tomkirbygreen

posted by esoteric

posted by deltalmg911

posted by evildictaitor

posted by sylvan

posted by evildictaitor

posted by klinkby

posted by vesuvius

posted by JChung2006

posted by Charles

posted by gaurav.net

posted by BSalita

Also, would it be possible to include links to papers or people referred to in your interviews? I often find myself hitting pause and web-grepping for the resource in question, it would be great to have them up front.

posted by tomkirbygreen

posted by sylvan

posted by gaurav.net

posted by RichardRudek

Re: Cutler, he's just not interested in this type of thing (being "interviewed" - these are conversations, really, not interviews per se...). There's nothing more to it...

I'll try and provide more links to content mentioned in conversations going forward. Thanks for the feedback.

C

posted by Charles

posted by Frank Hileman

posted by sylvan

posted by staceyw

posted by staceyw

posted by sylvan

staceyw wrote:  I see what your saying, but lets analyze that.  Essentially, that is a classic ReaderWriter lock sample.  You need the sync, because you never know who the last action was, a reader or writer.  So you still need some kind of sync primitive to protect the invariants. One may say, lets keep the message queue for writers, but let readers read properties directly. But here we have couple issues.  You still need lock to insure atomic reads (i.e non cache and non torn).  Second, you have possible coordination issues the runtime could never know and only your logic knows.  For example, your object may intentionally not be popping the queue (sort of a working blocking operation) queue until it completes work for last task - as maybe order is important or maybe is waiting on various replies.  There is all kinds of reasons order could be important and you can't reliably short circut that in general case.  So only the Object knows best.  As far as Perf goes, yes the message passing has some cost.  But so do ReaderWriters and Monitors.  When you look at the "net" performance, I think it probably is a wash or better with message passing.  Costs such as complexity and correctness proof are much less from the start.  There is many other benefits you can't get with locks or even trans memory.  You can get order symatics, self messaging, throttling, naturally async, pipelining, natural composition, loose binding, and others. Think Juval Lowy nailed it here. Every class needs to be a service: http://channel9.msdn.com/ShowPost.aspx?PostID=349561#349561

The problem is that the action you want to do may be "read value, do lots of complicated logic that takes a fairly long time, then you may decide to either do nothing, or update the value". If you're going to have a single owner of the data that handles this as a service (with an ad-hoc transactional protocol) you'll get contention. Let's for the sake of argument say that the computation that needs to be done before we know if we need to update takes a full second and you'll see how performance would be dreadful with even a few dozen threads accessing this data (even if actual updates are highly unlikely).

You can't just separate reading/writing into two separate requests either because you *need* transactional semantics. You need to know for sure that you read a value, then you decide to update, and the value won't have changed. With message passing that basically means "one client at a time please". I.e. horrible contention. You could do the equivalent of the usual locks/monitors business but that's what we were trying to get away from in the first place (they don't compose, and they're a nightmare to get right under complicated - i.e. realistic - scenarios where the set of locks you need to take depend on computations you can only do once you've already taken a bunch of other locks)!

With transactions the operations on the objects would still be owned by the objects (because it "knows best"), but the actual code would run on the caller's thread, meaning that all your clients can run at the same time and in 99.9999% of the cases there is zero contention, and everything scales almost linearly with the number of cores, and we're happy.

I agree that totally isolated threads are a better than shared state threads for correctness (but if all you want is parallelism, then tasks are even better, and data parallelism is even better than that), but there are *many* real world scenarios where shared state is crucial. Only having message passing is a non-starter for general purpose programming. We NEED a practical and composable (i.e. not locks) way of synchronising access to shared mutable state. Transactions is the only technology I'm aware of that does this currently.
...quote]


I agree transactions are very important abstraction here.  And they need to work with db transactions also. So there is some interesting work there.  I am not sure STM is required to pull this off.  The new runtime/language abstractions could do this by wrapping access to classes with proper behaviors.  I would think we need optimistic concurrency transactions so remote and local behavior could be same abstraction.

class MyClass
{
   string Name;
   int Count;
}

MyClass mc = ...
MyClass mc2 = ...

tryTransaction(mc,mc2) // OCC trans started on mc,mc2. mc's inside block are a copy.
{
   mc.Name = "joe";
   mc2.Count++;    
} // Commit. Runtime updates mc in batch and uses memory barrier to flush writes. Skipped if no writes.
catch(Exception ex)
{
  // trans is rolled back.
}

mc.Count++;       // Error. Writes must be inside OCC trans.
int i = mc.Count; // Reads ok outside trans.

TMK, expensive memory barriers would still be needed, but still cheaper then contenting explicit locks.  However, at lease the runtime does this for us and could dynamic pick the fastest way (i.e. Interlocks, Thread.MemoryBarrier, etc).  They could push this down even farther in the stack by changing the clr memory model somehow to address this.

posted by staceyw

posted by sylvan

TMK, STM is still an open research problem (at least from MS perspective). IMO, STM proper is more an implementation detail, I am still at the Abstraction level here. As Burton says, STM is the big hammer. It tries to solve the larger, more general problem for all memory access. Maybe it is used below the abstraction (if it ever gets done), or maybe not. But, in concert with the compiler and runtime I think they can pick out the core ideas and make it work now with combo of language, compiler, and runtime.

Method above would also support orElse and maybe condition variables at top of block.

tryTransaction(class)
{
  // stuff.
}
orElse
{
  // other stuff.
}
orElse
{
   retry 5; // retry 5 times or fail. TM keeps count down.
}
catch
{
}

My experiment here is that we handle invariants at the *class level, not the variable level as such. There is no change log, there is only the original copy of class(s) at the start of transaction stored by the TM. So all invariants of the class are always true for Readers and you can't get "temporary" inconsistent state inside transactions as shown in http://en.wikipedia.org/wiki/Memory_transactions in "Implementation issues". If a writer transaction fails, the Original copy is but back atomically. A writer is always first a reader of the class(s) in the transaction.

"I assume you don't really want to specify the objects that you keep track of up front either (since that brings us back to the original problem where we don't really know what variables we need to update until we've started the transaction)."

As above, this copies the object upfront. And all changes are applied or none of them are.

"Also, don't know why reads need to be okay outside transactions, since you could easily just do a single-statement transaction doing the read."

You can do reads inside a trans. In fact, that would be the only way to ensure consistent reads of all the members of a class as you get a "snapshot" of the class. However single reads outside (i.e. Length, Count, etc) could be allowed as a transaction does impose overhead that may not be needed in some cases such as just reading current state for display purposes (i.e. Progress). That said, it may be too easy to shoot the foot if this was allowed. Not sure on that one.

Interesting topic. Hope they are having fun.

posted by staceyw

Well that would be the deal breaker then. It seems to me that many of these transactions would have a "potential" set of affected objects that is much larger than the actual set for any given transaction (as the transaction would be likely to have control flow in it). So the overhead of copying objects you didn't actually need, and copying objects back that you didn't actually write to (which is what I assume you're talking about, as keeping track of the objects you actually write to amounts to basically a transaction log, and then why not just use STM?) would be very high indeed.

So again this is only a tiny improvement on locks really, since a transaction that commits would cause all other in-progress transactions to be aborted, even if they don't actually overlap (which is similar to how taking all the locks you may need causes contention even in cases where there are no actual conflicts). My intution tells me that for "real" applications (i.e. the ones where locks and monitors simply aren't tractable) many transactions would suffer from this.

So again, I think we need a solution where you can read and write to variables however you want, and have the conflicts resolved only when they actually occur, rather than doing some sort of conservative estimate. This key IMO. Almdahl's requires us to be very careful about not artificially limiting the amount of parallelism we can get by doing these kinds of conservative estimations (because if we do so, then that will quickly become our bottle neck when the number of threads increases).

posted by sylvan

posted by evildictaitor

posted by sylvan

sylvan wrote:


Or if you do check for actual overlap before rolling back, then you lose isolation since a potentially overlapping transaction can survive the commit (you can read variable X before a transaction commits a change to X and Y, and then you read Y afterwards. But now the X and Y that you've read aren't consistent anymore, since X is from before the last change, and Y is from after), how would you solve that without a transaction log to check at the end of the transaction to verify that the state that was read is consistent?

posted by evildictaitor

evildictaitor wrote:



sylvan wrote:  Or if you do check for actual overlap before rolling back, then you lose isolation since a potentially overlapping transaction can survive the commit (you can read variable X before a transaction commits a change to X and Y, and then you read Y afterwards. But now the X and Y that you've read aren't consistent anymore, since X is from before the last change, and Y is from after), how would you solve that without a transaction log to check at the end of the transaction to verify that the state that was read is consistent?

That's pretty easy. You can check at compile time what the read/write state is on various variables and associate them with the instruction pointer in the function

posted by sylvan

sylvan wrote:


In fact, if my IP is right at the final "return" statement of a transaction, then wouldn't this bit field be the same as my "potential set" of touched variables, even though the actual set of touched variables could be empty?

sylvan wrote:


If there's one thing I think we should avoid like the plague, it's introducing anything which may reduce the degree of parallelism we can see in a program. Almdahl's law scares me. We may not have hit it yet, but it's coming at us at 300mph and it's like a big brick wall on the horizon.

sylvan wrote:


Without actually logging what gets done, I don't see how we could easily check wether the transaction actually conflicts. Though I would be interested in seeing an approach to solving this issue (a transaction seeing inconsistent state) in a regular STM system using a simliar approach (i.e. right after a commit, check any potentially overlapping transaction's current log, and if the read set in those overlaps the write set in the transaction you're commiting, you can restart it).

sylvan wrote:


... which tells me that perhaps this may have terrible performance characteristics (e.g. due to that big global locking you're doing everytime something commits - ouch!), as well as being too conservative.

posted by evildictaitor

evildictaitor wrote:


Determining whether or not a transaction collision occurs by definition needs a global lock on the transactions and a pause on the threads.

posted by sylvan

sylvan wrote:


Couldn't you just (write-)lock the data you've read/written when trying to commit (in some global ordering)? That way you wouldn't lock *all* transactions, only the ones who try to do anything to the data you've needed.

sylvan wrote:


You still need to "fix" any transactions that get into an infinite loop or something due to an inconsistent view of the world, but you could do  a check on each thread switch, or GC or something, and of course in their own commit (if they get that far).

posted by evildictaitor

posted by Frank Hileman

posted by Frank Hileman

Frank Hileman wrote:

In message oriented systems, erlang, scala, etc, the isolated, message passing units are more lightweight than threads. The idea is to get away from the traditional thread with its heavy stack. Message passing is a robust, proven way of isolating state, that can scale well. Most people believe message passing is easier than locks, which do not scale well. Message passing in conjunction with functional programming (erlang) has proven successful for difficult concurrent telecommunications applications.

Transactions will always be needed for some types of applications, but transactional memory is a new thing, that to me, seems more of a hack to keep holding onto older ways of working.

posted by sylvan

posted by evildictaitor

evildictaitor wrote:  The point of transactions is that you never have inconsistent state. Whenever a transaction does a write, it clones the object and writes to the clone, and only when it commits does it write to the shared memory.  You can then cancel any transactions which might have read or written to these values (and would have inconsistent state if they continued), and simply free their memory and restart them.

posted by sylvan

posted by sylvan

sylvan wrote:


However, the suggested strategy of specifying transactional variables up front would have problems with scenarios where the transaction variables aren't known at compile time.

sylvan wrote:


E.g. if you read transactional variables from a transactional channel, and do transactional updates on them. Since those transactional variables can come from any other thread that has access to the channel (and depend on user input or whatever), and you don't even know how many of them you'll get, there's no way of producing a static lookup of which variables have been read based on the instruction pointer.

sylvan wrote:


As far as I can see you either need a transaction log, or you disallow transactional variables as first class citizens. So I'm not sure how well the log-less idea would work in practice (it seems to me that storing transactional variables inside other transactional variables would be very common, e.g. when you send a message to another thread and also supply a message channel for that thread to send its reply).

posted by evildictaitor

posted by staceyw

posted by Frank Hileman

posted by Frank Hileman

posted by Frank Hileman

evildictaitor wrote:


I fail to see why. All of the variable sites are known at compile time (by definition they are on the stack).

evildictaitor wrote:


Again, I can't think of a good reason to spawn multiple threads within a transaction.

Frank Hileman wrote:

Again, assuming you do not mean "threads" but some lightweight process concept, this is a problem for the message dispatcher, not the programmer. The dispatcher can recognize a sequence of many messages retrieving data, and they can all be run in parallel. There is no need to serialize the message processing until state is mutated. That is why messaging and functional programming work so well together. Any locking or true OS threads are hidden to the programmer.

posted by sylvan

posted by Frank Hileman

posted by sylvan

sylvan wrote:


Yould read a TVar containing a filter function, and another TVar containing a list of TVars, and then filter this list based on the filter function to get a reduced list of TVars, and then modify each of them based on the value of yet another TVar, etc. etc. How could you possibly know which values have been written to when the IP points "past" this code? The number of TVars that you have modified is not statically known, the filter function is not statically known, and the list of TVars itself is not statically known.

sylvan wrote:



evildictaitor wrote:  Again, I can't think of a good reason to spawn multiple threads within a transaction.

I haven't said anything about spawning multiple threads within a transaction?

posted by evildictaitor

posted by sylvan

posted by evildictaitor

posted by Frank Hileman

posted by sylvan

Frank Hileman wrote:




Your second argument, regarding N reads and M writes, you claim is solved better by a transaction. All you are doing is breaking up the granularity. You can do the exact same thing with messages. Instead treating the whole world as one process, break up the writes into messages to M processes.

Frank Hileman wrote:


The point is you can do anything you wish with message passing. It is a fundamental building block, and can scale as well as your design permits. If your design has no need for atomic composite commits, you can do that. If you do need atomic composite commits, you can do that as well.

posted by sylvan

posted by Frank Hileman

http://softwaremaven.innerbrane.com/2007/12/python-versus-erlang-for-mmog.html

That is only distributed server stuff. It seems message passing would work well on clients as well, given that the game might be modeled as many independent actors interacting with one another.

posted by Frank Hileman