Cond: A Case Study; or Shipping Fn Channels

A defense against killing sync.Cond, and explaining it so that more people will have it as part of their toolbox! Includes full advertisement!

Transcript

1. Cond: A Case Study; or
   Shipping Fn Channels
   Reed Allman
   @rdallman10
   

   View Slide

2. But first, welcome to 2018, have an ad
   

   View Slide

3. View Slide

4. Three cloud vendors ruled the FaaS galaxy
   

   View Slide

5. We, too, have a cloud, but...
   

   View Slide

6. We want to be different
   

   View Slide

7. And users don't want to wait 4 years for native support for
   their favorite programming language
   

   View Slide

8. And since users are developers, they may have a thing or
   two to contribute
   

   View Slide

9. So we started building our own cloud FaaS offering, in the
   open, and container native
   

   View Slide

10. So that we may one day rule the Galaxy
    

    View Slide

11. https://fnproject.io/
    P.S. We can also pay you to work on it full time, say hi!
    

    View Slide

12. Onto the show
    

    View Slide

13. I'd like to talk to you about sync.Cond
    

    View Slide

14. One of the least used, reviled constructs in go
    

    View Slide

15. View Slide

16. So what is this abomination?
    

    View Slide

17. View Slide

18. OK, that didn't help. Why does it exist in the first place?
    

    View Slide

19. View Slide

20. [1] Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau, Operating Systems: Three Easy Pieces, 30.1
    

    View Slide

21. Dude, show an example already
    

    View Slide

22. View Slide

23. OK, but go has channels? We don't need no stinkin' cond
    

    View Slide

24. First, define the problem:
    ● Parent wait for children to finish
    ● Producer/Consumer problem
    

    View Slide

25. ● Parent wait for children to finish (sync.WaitGroup)
    ● Producer/Consumer problem (make(chan))
    

    View Slide

26. So we can go home now?
    

    View Slide

27. OK, maybe we should define our problem
    [1] https://lamport.azurewebsites.net/pubs/state-the-problem.pdf
    

    View Slide

28. We need to allocate resources from a host (disk, memory,
    CPU) dynamically per container, and when full, wait for
    resources to free up.
    Meanwhile, if any of the existing containers free up, we can
    use them and abandon attempting to allocate more
    resources.
    

    View Slide

29. View Slide

30. This problem is called a covering condition
    [1] Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau, Operating Systems: Three Easy Pieces, 30.3, 2015
    [2] B.W. Lampson, D.R. Redell, Experience with Processes and Monitors in Mesa, pg. 105, 1980
    

    View Slide

31. But channels taste like panacea?
    

    View Slide

32. View Slide

33. We need to wake up all threads when a container exits,
    because multiple containers could fill its void and certain
    containers may not fit at all
    

    View Slide

34. But you can close a channel to broadcast!
    

    View Slide

35. While channels can do broadcast, afterwards the channel is
    closed. We really need a channel that remains open but
    allows broadcasts.
    

    View Slide

36. Mostly, it's an issue of complexity. We could implement this
    all with channels, but we'd need a few things:
    ● requests wait over resource allocation channel
    ● a thread (or synchronization) that manages resource
    allocation channels & their requested sizes (FIFO), and
    separately receives wake up calls when resources are
    freed and doles them out (and handles when allocs gave
    up efficiently)
    ● to figure out whatever the hell data structure ^ is
    

    View Slide

37. ... or we can just grab a handy dandy sync.Cond
    

    View Slide

38. View Slide

39. We also need to handle timeouts on <-ctx.Done()
    

    View Slide

40. sync.Cond and channels don't mix out of the box, so wouldn't
    we be better off just doing this all with channels and get
    this fo free?
    

    View Slide

41. View Slide

42. https://github.com/fnproject/fn/blob/54ba49be65c274d2a
    e52c115035211549079348e/api/agent/resource.go#L42
    

    View Slide

43. What we accomplished:
    ● Now we can wait for resources OR a container to free up,
    OR a request timeout, using a select statement
    ● You were duped into watching an advertisement for the
    Fn Project under the false pretense that you might learn
    something from somebody you have never heard of
    

    View Slide

44. A context, a context, my kingdom for a context?
    

    View Slide

45. Thanks!
    Check us out: https://github.com/fnproject/fn
    We’re hiring engineers and evangelists!
    Reed Allman
    Principal Eng @ Oracle
    @rdallman10
    

    View Slide