John Lam and Martin Maly: Deep DLR

“I don’t use the internet any more because they can steel every thing” in context that was a very funny comment.
Regarding the Sleeping Barber Algorithm and with out breaking the demonstration. Wouldn’t you want to have as many barbers as you have chairs?
jason818_253.33 wrote:Regarding the Sleeping Barber Algorithm and with out breaking the demonstration. Wouldn’t you want to have as many barbers as you have chairs?
![]() |
jason818_253.33 wrote:
Regarding the Sleeping Barber Algorithm and with out breaking the demonstration. Wouldn’t you want to have as many barbers as you have chairs? |
CRPietschmann wrote:This analogy does make the problem sound simple.
dot_tom wrote:Wow. 2008 is shaping up to be the best year to date for video interviews on Channel 9! How are you guys going to top this?
staceyw wrote:Here is a CCR implementation of the Sleeping Barber(s).
Optionally, we can add barbers (threads).
As shown, this is actually a pretty clean pattern using Ports and lamdas and hides the locks and such in the runtime. User level locks on shared state could still be needed in the lambda. So it is not something that has to be "baked" into a language itself as this works pretty clean as a library.
I really like a few of ideas in this video in general:
1) I like the ccr Port abstraction. For some reason I like endpoints and messages.
2) I like the idea of Pre and Post conditions. This could be added to c#. Think spec# has.
3) I like the idea explicit handling of Query and Command on shared state. It allows tooling and static and runtime checks.
4) I like the idea un-named types like Tuples. c# has anonymous types, but you can't pass them around.
5) I love the idea of Transactions for object state and have them work with normal DB transactions for rollback. That seems to be a winning pattern for handling shared state and something like CCR below for handling concurrency and coordination.
private void button20_Click(object sender, EventArgs e)
{
// Have 1 Barber and N chairs. You can add Barbers (i.e. Threads in the pool) by changing the Dispatcher ctor.
Port<string> chairsPort = new Port<string>();
DispatcherQueue dq = new DispatcherQueue("Barber", new Dispatcher(1, "BarberPool"));
Arbiter.Activate(dq, Arbiter.Receive(true, chairsPort, (string name) =>
{
Thread.Sleep(100); // Time to cut hair.
Console.WriteLine("Customer {0} thanks the barber for the cut on thread {1}.", name, Thread.CurrentThread.ManagedThreadId);
}));
for (int i = 0; i < 15; i++)
chairsPort.Post("Customer" + i);
}
Once again this video made me think of a really cool addition I'd love to see Channel 9 add to such video interviews. Charles, is there any chance you could ask your interviewees to state the last comp.sci book they read and enjoyed? I'm thinking the 'tradition'
would be that it wouldn't even directly have to have anything to do with the subject of the video in question. You could then include the book details in addition to the usual interviewee home page link. Often times when watching or listening to the folks
you interview I'm left thinking: 'Wow, I'd love the scan the titles on their technical bookshelf!'. Am I alone in this?
dot_tom wrote:Once again this video made me think of a really cool addition I'd love to see Channel 9 add to such video interviews. Charles, is there any chance you could ask your interviewees to state the last comp.sci book they read and enjoyed? I'm thinking the 'tradition' would be that it wouldn't even directly have to have anything to do with the subject of the video in question. You could then include the book details in addition to the usual interviewee home page link. Often times when watching or listening to the folks you interview I'm left thinking: 'Wow, I'd love the scan the titles on their technical bookshelf!'. Am I alone in this?
dcharles wrote:Truely old school, he wrote his algorithm on paper! how many programmers do that today?![]()
sokhaty wrote:
staceyw wrote:
Here is a CCR implementation of the Sleeping Barber(s).
Optionally, we can add barbers (threads).
As shown, this is actually a pretty clean pattern using Ports and lamdas and hides the locks and such in the runtime. User level locks on shared state could still be needed in the lambda. So it is not something that has to be "baked" into a language itself as this works pretty clean as a library.
I really like a few of ideas in this video in general:
1) I like the ccr Port abstraction. For some reason I like endpoints and messages.
2) I like the idea of Pre and Post conditions. This could be added to c#. Think spec# has.
3) I like the idea explicit handling of Query and Command on shared state. It allows tooling and static and runtime checks.
4) I like the idea un-named types like Tuples. c# has anonymous types, but you can't pass them around.
5) I love the idea of Transactions for object state and have them work with normal DB transactions for rollback. That seems to be a winning pattern for handling shared state and something like CCR below for handling concurrency and coordination.
private void button20_Click(object sender, EventArgs e)
{
// Have 1 Barber and N chairs. You can add Barbers (i.e. Threads in the pool) by changing the Dispatcher ctor.
Port<string> chairsPort = new Port<string>();
DispatcherQueue dq = new DispatcherQueue("Barber", new Dispatcher(1, "BarberPool"));
Arbiter.Activate(dq, Arbiter.Receive(true, chairsPort, (string name) =>
{
Thread.Sleep(100); // Time to cut hair.
Console.WriteLine("Customer {0} thanks the barber for the cut on thread {1}.", name, Thread.CurrentThread.ManagedThreadId);
}));
for (int i = 0; i < 15; i++)
chairsPort.Post("Customer" + i);
}
Well, it looks to me that support for Queries and Commands would (almost) automatically require transactional support.
No one would like to read partial state, would they?
And in a way, it proves the point of functional programmers are trying to make - when you need to change the world, you have to create a new copy of it.
Whoever was reading the world at the moment you decided to modify it, would continue to use the "old" consistent version of it.
After you are done changing the world and committed your changes, all the new readers would see the new updated version. The old version will hang around long enough for all active readers conclude their activities and be "garbage collected" as soon as its no longer required.
Which is sort of what databases already do to implement non-blocking consistent reads.
So, it seems that eventually runtime environment will be a database with a common VM on top of it.
But that approach has its own issues, namely a requirement to have universal change sequence number to mark world versions.
Hmmm, is it a coincidence that Eric Meijer is said to be working on SQL Server these days?
staceyw wrote:
sokhaty wrote:
staceyw wrote:
Here is a CCR implementation of the Sleeping Barber(s).
Optionally, we can add barbers (threads).
As shown, this is actually a pretty clean pattern using Ports and lamdas and hides the locks and such in the runtime. User level locks on shared state could still be needed in the lambda. So it is not something that has to be "baked" into a language itself as this works pretty clean as a library.
I really like a few of ideas in this video in general:
1) I like the ccr Port abstraction. For some reason I like endpoints and messages.
2) I like the idea of Pre and Post conditions. This could be added to c#. Think spec# has.
3) I like the idea explicit handling of Query and Command on shared state. It allows tooling and static and runtime checks.
4) I like the idea un-named types like Tuples. c# has anonymous types, but you can't pass them around.
5) I love the idea of Transactions for object state and have them work with normal DB transactions for rollback. That seems to be a winning pattern for handling shared state and something like CCR below for handling concurrency and coordination.
private void button20_Click(object sender, EventArgs e)
{
// Have 1 Barber and N chairs. You can add Barbers (i.e. Threads in the pool) by changing the Dispatcher ctor.
Port<string> chairsPort = new Port<string>();
DispatcherQueue dq = new DispatcherQueue("Barber", new Dispatcher(1, "BarberPool"));
Arbiter.Activate(dq, Arbiter.Receive(true, chairsPort, (string name) =>
{
Thread.Sleep(100); // Time to cut hair.
Console.WriteLine("Customer {0} thanks the barber for the cut on thread {1}.", name, Thread.CurrentThread.ManagedThreadId);
}));
for (int i = 0; i < 15; i++)
chairsPort.Post("Customer" + i);
}
Well, it looks to me that support for Queries and Commands would (almost) automatically require transactional support.
No one would like to read partial state, would they?
And in a way, it proves the point of functional programmers are trying to make - when you need to change the world, you have to create a new copy of it.
Whoever was reading the world at the moment you decided to modify it, would continue to use the "old" consistent version of it.
After you are done changing the world and committed your changes, all the new readers would see the new updated version. The old version will hang around long enough for all active readers conclude their activities and be "garbage collected" as soon as its no longer required.
Which is sort of what databases already do to implement non-blocking consistent reads.
So, it seems that eventually runtime environment will be a database with a common VM on top of it.
But that approach has its own issues, namely a requirement to have universal change sequence number to mark world versions.
Hmmm, is it a coincidence that Eric Meijer is said to be working on SQL Server these days?
yes. That is essentially what we came up with in another thread on object transactions. Transactions would atomically make a copy of the invariants. A writer could make updates to its' version and "try" update. I think it would a ~simple matter to extent object meta data to include a seq number.
dcharles wrote:Truely old school, he wrote his algorithm on paper! how many programmers do that today?![]()
foostar wrote:I'm not convinced that SCOOP can work. The problem I see with it is that it allows for arbitrary sharing of state among concurrently executing objects. If it can be made to work then the compiler will probably have to make such conservative decisions wrto synchronization that performance will be a tiny fraction of the theoretical optimum.
Very good video. This was very nice to see Bertrand Meyer speaking about his work. Thanks for bringing this.
BTW, does he have to take into account the customers who do not see a barber and walk away? That was very funny!!