From: Robert Klemme <shortcutter@...>
Date: 2012-05-16T16:41:57+09:00
Subject: Re: How to ensure that a block runs entirely after other threads? (Thread.exclusive does not "work")

On Wed, May 16, 2012 at 9:31 AM, Matthew Kerwin <matthew@kerwin.net.au> wrote:

> Keeping in mind that things like "the screen" are a resource; so if
> you want to synchronise your output you can create a lock to restrict
> access to STDOUT, or any printing/writing methods, or whatever is
> appropriate.  I find reentrant read-write locks are the easiest
> synchronising mechanisms to keep straight in my head, but they could
> be pretty heavy overkill for some applications.

Matthew, why do you full quote _me_?  That's exactly what I said.

On Wed, May 16, 2012 at 9:33 AM, Iņaki Baz Castillo <ibc@aliax.net> wrote:
> First of all, as Eric said, Thread.exclusive does "nothing" in Ruby
> 1.9 (native threads), so I need to use something like Mutex, but that
> requires cooperation  from all the threads which could not be my case
> (I'm coding a Ruby library rather than a final application).
>
> But it's ok, I'll document that, in case the user wants to use
> multiple threads, it is his responsability to syncronize them.

That's a perfectly appropriate way to handle that: you don't want to
incur synchronization overhead for all users even if they do not need
access from multiple threads.  Even worse, there are cases where only
the user can decide which synchronization is appropriate.  For example
the infamous cache idiom

if cache.include? x
  y = cache.get(x)
else
  y = create_y(x)
  cache.put(x, y)
end

(I know, which Hash there are more elegant solutions - this is for
illustration purposes only.)

In this case you cannot guarantee consistency by internally
synchronizing all methods of "cache" if it must be avoided that two
threads invoke create_y() for the same x.

Cheers

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/