On Wed, May 16, 2012 at 9:31 AM, Matthew K. [email protected]
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, Iaki Baz C. [email protected]
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)
y = create_y(x)
(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.