Comment Feed for Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers (Going Deep on Channel 9)

Re: Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

sulivan04 — Fri, 17 Oct 2008 12:27:57 GMT

Anyone who want to convert Mod video files to mpg, mpeg, avi, wmv video formats you can use Aiseesoft Mod Video Converter. You can free download it and have a try.
http://www.aiseesoft.com/mod-video-converter.html

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

pierreleclercq — Sun, 06 Apr 2008 10:23:07 GMT

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!! :D

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

Christian Liensberger — Wed, 02 Apr 2008 17:48:29 GMT

Awesome video!!! Please more of this kind, more nerd food :)

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

Frank Hileman — Wed, 02 Apr 2008 03:40:36 GMT

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.

Is this really true? My understanding is that SCOOP is very high level and there are a number of different ways it could be implemented internally. For example, it could be implemented on top of message passing?

I like the SCOOP concepts. Being a fan of design by contract for many years now, I like especially the way it works neatly with contracts. I would like to think foostar is incorrect in these assumptions.

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

foostar — Tue, 01 Apr 2008 21:24:42 GMT

The participants seem surprisingly ignorant of the state of the art in concurrent programming. Message passing architectures are old hat, and have been shown to be scalable; a lot of work is going into transactionactional memory and other non-blocking strategies, and so on, but I don't hear these being mentioned even in passing.

The Eiffel SCOOP mechanism was proposed over a decade ago, making the idea generations old in the software world, yet a functioning product still hasn't shipped. Why is that?

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.

Its one of those ideas that have a seductive elegance at first glance but ultimately turns into a dead end.

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

evildictaitor — Mon, 31 Mar 2008 04:33:02 GMT

dcharles wrote:
Truely old school, he wrote his algorithm on paper! how many programmers do that today?

Me for one. Excepting trivial functions, most of what I do requires me to think, and I can't do that without a bit of paper and a pencil.

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

Charles — Mon, 31 Mar 2008 03:52:02 GMT

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.

Interesting idea. Thanks for sharing.

Keep on GoodThinking,
C

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

William Stacey — Sun, 30 Mar 2008 23:38:42 GMT

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.

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

William Stacey — Sun, 30 Mar 2008 23:28:51 GMT

dcharles wrote:
Truely old school, he wrote his algorithm on paper! how many programmers do that today?

I used to write all my Cobol programs on paper first and work them out and debug them on paper. This was mainly because we had time limit on input and Run time for CPU. It actually worked out pretty well, because you could sit down and type the whole program in an hour or so and it was mostly debugged already. I would not do that today. As Erik has said before, today the IDE is so good, it is like "smart paper" that serves the same function as paper, but with other benefits.

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

Charles — Sun, 30 Mar 2008 22:15:05 GMT

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? :-)

That's a fine idea, dot_tom! Thanks for the suggestion.
C

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

Tom Kirby-Green — Sun, 30 Mar 2008 08:00:51 GMT

Hi DCharles. I'm guilty of frequently resorting paper based coding! :-) I keep meaning to get myself a cheap A4 scanner so I can archive these things. I often make myself walk away from my computer and go think somewhere else. Which usually results in algorthims being sketched on any available bit of paper. I often find it much easier to do 'think refactors' on paper than on the screen.

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

Tom Kirby-Green — Sun, 30 Mar 2008 07:54:14 GMT

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? :-)

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

dcharles — Sat, 29 Mar 2008 22:40:02 GMT

Truely old school, he wrote his algorithm on paper! how many programmers do that today?:D

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

Charles — Sat, 29 Mar 2008 19:31:52 GMT

Erik does in fact work on the same team that makes SQL Server (and other data-related technologies), which is a large and varied team, but he does not work on SQL Server specifically. Erik is first and foremost a language guru and his recent work was instrumental in making language features like LINQ possible (among other new functional-based constructs in C# and VB.NET). He's also the chief architect of Volta.

The Data Programmability team is full of innovators. Erik is one of them.

C

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

sokhaty — Sat, 29 Mar 2008 03:13:54 GMT

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?

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

martin_hughes — Fri, 28 Mar 2008 19:13:10 GMT

Very interesting video - as all of these Going Deep's have been.

RE the Sleeping Barber: Why not just temporarily impart the knowledge and know-how of how to cut one's own hair to each customer that comes along with instructions to come back and report how it went?

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

William Stacey — Fri, 28 Mar 2008 15:12:22 GMT

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);
}

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

Jonathan Merriweather — Fri, 28 Mar 2008 07:41:00 GMT

I enjoyed this. Thanks

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

Klaus Enevoldsen — Fri, 28 Mar 2008 06:54:31 GMT

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? :-)

There have been both hits and misses. 2007 was not the best year for channel9 videos. But you are right 2008 looks very promising: more videos on language, tools and process (development methods like Agile). A video about the new work item types in Rosario would be great...

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

Tom Kirby-Green — Fri, 28 Mar 2008 05:13:37 GMT

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? :-)

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

evildictaitor — Fri, 28 Mar 2008 01:30:41 GMT

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.

You've both misunderstood the crux of the Sleeping Barber problem. The problem is a problem not of speed or efficiency, but one of concurrency. The point is to serve the customers without experiencing process- (customer-) starvation or deadlock and the Sleeping Barber problem is a double-rendevous problem requring a more careful use of locks to achieve the correct result than you might think at first.

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

Chris Pietschmann — Fri, 28 Mar 2008 00:00:17 GMT

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?

This does inspire some thought.

Basically, a chair will contain a customer, and a barber is required to do the work. This pretty much means that the number of chairs is the number of slots in the queue. The number of barbers will be determined by how many processor cores you have.

So pretty much, the more processor cores you have, the more barbers you can have. You ideally want one barber for each processor core. So, the more processor cores you have and therefore the more barbers you have, the faster you'll be able to cut the hair of all the customers in the chairs.

This analogy does make the problem sound simple.

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

jason818_253.33 — Thu, 27 Mar 2008 20:56:19 GMT

“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?

Re: Expert to Expert: Erik Meijer and Bertrand Meyer - Objects, Contracts, Concurrency, Sleeping Barbers and Eiffel

Bent Rasmussen — Thu, 27 Mar 2008 18:48:15 GMT

HOLY CRAP! I have to watch this!