threading and concurrency

[Jonas Pfenniger]

2007/3/15, Michael Gorsuch <michael.gorsuch at gmail.com>:
> carmen - I'm not sure _how_ much this will really help you, but I
> recently explored a similar issue with an internal Camping app.
>
> In summary, I needed to make sure that all calls to a specific
> controller were always executed serially.  i.e. - if two calls came in
> at approximately the same time, the second call could not run until
> the first one finished.
>
> This was not a problem: I just included the 'thread' library and
> wrapped the code in a synchronize block.  The only requirement: I only
> run a single mongrel instance.
>
> Simple code example follows:
>
> **********
>
> require 'thread'
> ....
>
> class Create < R '/create'
>   def synchronize
>     mutex.synchronize {yield self}
>   end
>
>   def mutex
>     @mutex ||= Mutex.new
>   end
>
>   def get
>     synchronize do
>       # my code goes here...
>     end
>   end
> end
>
> ******************
>
> I hope this helps out some,
>
> Michael Gorsuch
> http://www.styledbits.com
>
>
>
> On 3/12/07, carmen <_ at whats-your.name> wrote:
> > hello all. ive come to the point where im thinking about deploying my 'rails on rails' app-development solution built in camping.
> >
> > mainly, im wondering what the barriers to thread-safety are.
> >
> > for db, i use redland, and afaik it spawns a single db connection for each find, and keeps a pool around to reuse. iow, no ActiveRecord.
> >
> > are class-vars a problem? theres one that i'd like to keep, a 'close' cache of triples in a normal ruby Array.. read/writes to this are fast (much faster than HTML generation in markaby, from what i can tell), but i guess they would need to lock the other threads briefly.
> >
> > for simplicity. i'd prefer a single interpreter process. otherwise i'm going to have to come up with some distributed cache invalidation scheme (typically the user load is 1-15, small workgroups, which loadwise is fine except they may experience a few seconds lag in their requests if eg a heavy SPARQL query is going on in another request)
> >
> > oh, and id like to hear 'sure, but you have to hack up the mongrel configurator slightly, and not do this' rather than 'just use a pack of mongrels'
> >
> >
> > cheers :)
> > _______________________________________________
> > Camping-list mailing list
> > Camping-list at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/camping-list
> >
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

Are you sure it's the right way to do ? It seems to me that an
instance of the controller is created on each request. So with your
approach, a mutex is created on each request and your don't have the
benefit of mutex locking. Adding an `at` before @mutex should do the
trick.

-- 
Cheers,
  zimbatm