14

I'm writing server-side logic for a Meteor app that has to update in-memory state in response to requests from the client. This application needs strong concurrency guarantees - in particular, I want to be sure that there is only one update executed at a time.

I'm trying to figure out if Meteor's concurrency model supports this. The documentation mentions that Meteor is multithreaded (which would be a problem), but after searching around, I get the impression that Meteor is actually uses fibers (explicitly scheduled threads). If that's true, then I'm safe as long as the part of my code that needs to run atomically doesn't make any Meteor calls (which involve IO and thus yield the execution lock).

Is this the case? Where can I find more information on Meteor's concurrency model?

disatisfieddinosaur
  • 1,502
  • 10
  • 15
  • I think you should implement locks by yourself for you in-memory storage or you can use mongo atomic operations. – Denis Aug 11 '13 at 15:56
  • If it helps, the documentation for the fibers library is [here][1] [1]: https://github.com/laverdet/node-fibers – Jonathan Warden Aug 11 '13 at 17:11
  • @Denis If I can implement in-memory locks because non-IO, non-yielding operations are atomic, then I don't even need them for this application. In any case, I want to know how concurrency in Meteor works for future information. This stuff should be clearly documented somewhere; it isn't. I'll probably end up going through the Meteor source code. – disatisfieddinosaur Aug 11 '13 at 22:56

2 Answers2

13

Alright, I looked through the Meteor source and here's how things work:

1) On the server-side, Meteor exclusively uses fibers to handle concurrency. Fibers are like threads, except that context must be explicitly yielded. This makes reasoning about concurrency easier, at the (potential) cost of some fibers starving others.

2) All calls to Meteor.call, Meteor.setInterval, and any Collection operations are wrapped in fibers. This means that all of these calls yield context.

3) In addition, any use of the fibers/futures module yields.

The upshot of this structure is that if you want to write atomic operations, just avoid accessing the objects provided by Meteor framework in the block of code that you want to make atomic. If this block really needs (say) a DB access, then you can implement in-memory locks without trouble, but for my application, this knowledge is enough. My core update function just needs to be called with all of the documents it needs from Mongo already read.

disatisfieddinosaur
  • 1,502
  • 10
  • 15
2

From the meteor docs:

In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. We find the linear execution model a better fit for the typical server code in a Meteor application.

http://docs.meteor.com/#structuringyourapp

Does anybody know the performance implications of this?

Cristian Garcia
  • 9,630
  • 6
  • 54
  • 75