I\'m trying to serve multiple requests concurrently in Rails 4, something I was able to do very easily with config.threadsafe! and Puma in Rails 3.
I invite you to read about the configuration options of config.threadsafe! in this article Removing config.threadsafe!
It will help you to understand better the options of config.threadsafe!, in particular to allow concurrency.
In Rails 4 config.threadsafe! is set by default.
In Rails 4 requests are wrapped around a Mutex by the Rack::Lock middleware in DEV environments by default.
If you want to enable concurrency you can set config.allow_concurrency=true. This will disable the Rack::Lock middleware. I would not delete it as mentioned in another answer to your question; that looks like a hack to me.
Note: If you have
config.cache_classes=truethen an assignment toconfig.allow_concurrency(Rack::Lock request mutex) won't take effect, concurrent requests are allowed by default. If you haveconfig.cache_classes=false, then you can setconfig.allow_concurrencyto eithertrueorfalse. In DEV environment you would want to have it like thisconfig.cache_classes=false config.allow_concurrency=trueThe statement: Which means that if config.cache_classes = false (which it is by default in dev env) we can't have concurrent requests. is not correct.
You can refer to this answer, which sets up an experiment testing concurrency using MRI and JRuby. The results are surprising. MRI was faster than JRuby.
The experiment with MRI concurrency is on GitHub. The experiment only tests concurrent request. There are no race conditions in the controller. However, I think it is not too difficult to implement example from the article above to test race conditions in a controller.