views:

38

answers:

1

I'm working on an API integration project in Ruby and I was about to create a class method to somewhat follow what Rails does with the finder methods but I stopped short of doing so because I'm concerned I might introduce a race condition.

I wouldn't be storing anything within the member variables, just instantiating objects with the the class method and making external API calls, so everything would be locally scoped (within the class method). Still, isn't there a potential of having a race condition as multiple threads pass through this class method? How do the Rails finder class methods avoid this? Or am I not understanding something at a more fundamental level here?

+1  A: 

It's possible you're not understanding how threads work, or that you're not describing some part of your problem that would be the source of a race condition.

Merely calling a method in two different threads isn't sufficient to cause a race condition. Unless there's some shared resource that might be in an inconsistent state because another thread is in the middle of using it, a race condition isn't really a problem.

If all of your variables are scoped to the method, then the only source of a race that I can glean from your description of the problem might be the API calls. If it's possible that while one thread is in the middle of accessing the API, another comes through and restarts whatever interaction was going on, and that would be problematic, then you might have a race problem.

Judson
Yeah, I'm concerned about the external API calls specifically. So basically, as long as there aren't any shared resources at any point within the function, then I should be ok it sounds like. Thanks!
Ruben