Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

ssylvan

ssylvan ssylvan

Niner since 2009

  • E2E: Herb Sutter and Erik Meijer - Perspectives on C++

    @WhatWouldBukowskiDo: But that has nothing to do with actors. You can do the same coarse-grained API-design with locks or synchronized methods too. Like I said, actors may expose more parallellism (because they run on their own lightweight thread), but they don't improve correctness. At the end of the day it's just locks in a different form.

    I'd also somewhat disagree with the API suggestion, actually.

     

    In a single-threaded scenario it's generally regarded better to have a few generic methods that can be easily composed to do fifty things, than have fifty "big" methods (i.e. the API should be "minimal and complete"). It's only when you bring in locking that you need to specialize and pull things together into "bigger" methods so that you can carefully manage locking for some common tasks. That may well be the best strategy on balance when you do have to worry about locking, but it's at least worth noticing that you're going against normal guidelines for good API-design when doing so, which indicates that the concurrency model has some room to improve.

    Ideally we could still use a "minimal and complete" API design that affords composability, while maintaining thread safety. This is, for example, what STM is designed to solve.

  • E2E: Herb Sutter and Erik Meijer - Perspectives on C++

    @staceyw: I guess the point Eric was making is that if you start doing that sort of stuff you've just reinvented locks again (on top of actors, but still). You either get races, or deadlocks. Also, this kind of lock is probably less efficient because it's layered on top of another abstraction.

    Actors might help enable some by exposing latent concurrency, but it does nothing to improve safety. It's still just as tedious, error-prone and above all manual as it ever was.

  • Mads Torgersen: Inside C# Async

    So maybe I'm missing something, but is there a way to create little pieces of asynchronous work without having to pull everything out of the method into its own async method? E.g. to use the WhenAll example... So if you start with something like

    public async Task<List<Result>> GetResults()
    {
        var results = new List<Result>();
        foreach (var url in urls )
        {
             UnprocessedResult r = await DownloadResult(url);
             results.Add( processResult(r) );
        }
        return results;
    } 

     

    But then to get the improved parallelism that they talk about in the video, you want to use WhenAll, so you do this:

    public async Task<List<Result>> GetResults()
    {
        var results = new List<Result>();
        var tasks = new List<Task<result>>();
        foreach (var url in urls )
        {
             tasks.Add (DownloadResult(url));
        }
        await Task.WhenAll(tasks);
        foreach (var t in tasks)
        {
             results.Add( processResult(t.Result) );
         }
        return results;
    } 

     

    The problem is the fact that we have to do the "continuation" of each task in a separate loop. One way of fixing this is to move the loop body out into its own async method which awaits DownloadResult and then processes it afterwards. Then the main function can just WaitAll on *those* tasks. But having to create a brand new method for tiny "post-async-fixups" is onerous. It would be cool if we could just create async lambdas, which we then call immediately, which then returns a task with the body inside it. E.g.:

    public async Task<List<Result>> GetResults()
    {
        var results = new List<Result>();
        var tasks = new List<Task<UnprocessedResult>>();
    
        foreach (var url in urls )
        {
             // notice async lambda, that gets called immediately
             tasks.Add( async () => {
                     var r = await DownloadResult(url);
                    results.Add( processResult( r ) );
             }() );        
        }
    
        await Task.WhenAll( tasks );
        return results;
    } 

    You can't call a lambda like that, so even with async lambdas it would be ugly:

    public async Task<List<Result>> GetResults()
    {
        var results = new List<Result>();
        var tasks = new List<Task<UnprocessedResult>>();
    
        foreach (var url in urls )
        {
             // notice async lambda, that gets called immediately
             Func<Task<UnprocessedResult>> f = async () => {
                     var r = await DownloadResult(url);
                    results.Add( processResult( r ) );
             };
             tasks.Add( f() );        
        }
    
        await Task.WhenAll( tasks );
        return results;
    }

    Perhaps an alternate syntax which does the above would be in order?

    public async Task<List<Result>> GetResults()
    {
        var results = new List<Result>();
        var tasks = new List<Task<UnprocessedResult>>();
    
        foreach (var url in urls )
        {
             tasks.Add( async {
                     var r = await DownloadResult(url);
                    results.Add( processResult( r ) );
             });        
        }
    
        await Task.WhenAll( tasks );
        return results;
    }

    Where "async{ ...}" just whips up a simple local Task that does the stuff in the body.

  • E3 2010: Highlight Reel from The Microsoft Press Briefing

    Kinect is very different from a normal controller. That's why there's a separate "hub" for kinect in the dashboard which optimizes for Kinect-based navigation. You wouldn't want to work your way through a controller-centric UI using a gesture based input. It would be frustrating and annoying.

     

    The audience does consist of soccer moms and six year olds. That's exactly the audience that MS hasn't been able to tap into yet, and exactly the audience that needs to start buying Xbox 360s for it to move beyond the tens and into the hundreds of million units. Don't worry - the core games and normal controller aren't going anywhere. Just because there are games and input devices that aren't for you doesn't mean you have to stop playing the games you do like.

     

    Yes, Kinect Sports and Adventures may well be "obvious", but they're "obvious" for a reason - because they're obviously great fits for this kind of technology and are loads of fun. It would be stupid to not have those games for Kinect. You can't not do fun games because you think they're not unexpected enough. If that had been the case we would've never see wii sports in the first place. 

  • E3 2010: Highlight Reel from The Microsoft Press Briefing

    I don't know what people were expecting. It was always pretty clear to me that Kinect is about casual/physical gaming, not about core games (lack of buttons should be a hint). You may see it tacked on as a gimmick to some core games (Forza did have head tracking in the cockpit view), but really this isn't about core gamers, it's about expanding the market to the casual crowd (which they even stated fairly explicitly).

     

    That's fine though, it's not like the core games disappear just because there's also casual games available. Halo, Call of Duty, Crackdown, Fable, etc. are all coming this year for the core crowd, so I'm not sure why the existence of Kinect Sports is cause for disappointment for those who don't like that sort of stuff anyway.