On 2002.05.31, Morris, Chris <chris.morris / snelling.com> wrote:
> I wrote this ThreadSafeArray class. Seems to work, but I thought I'd throw
> it out here for review. Any holes in this approach?

I'd be concerned about:

>   def method_missing(method, *args, &block)
>     @mutex.lock
>     begin
>       @internalArray.send(method, *args, &block)
>     ensure
>       @mutex.unlock
>     end
>   end

Out of paranoia (and because I don't know how Mutex#lock is
implemented) I might be inclined to do:

>   def method_missing(method, *args, &block)
>     begin
>       @mutex.lock
>       @internalArray.send(method, *args, &block)
>     ensure
>       @mutex.unlock
>     end
>   end

Move the lock inside the begin/ensure/end block.  This way,
you don't have a case where Mutex#lock fails throwing an
exception but you still access the array.

On 2002.05.31, ts <decoux / moulon.inra.fr> wrote:
>  It depend what you call a hole. What do you expect with ?
> 
>   a = ThreadSafeArray.new
>   b = ThreadSafeArray.new
>   p a == b

On 2002.05.31, Morris, Chris <chris.morris / snelling.com> wrote:
> 
> Good question. Obviously, it's false with the given code. I think that's
> fine for my purposes at least. Even if I wanted it to eval to true, I'm not
> sure how I could pull that off though. I guess I'd have to do an element by
> element comparison, perhaps?

Why not this:

  def ==(x)
    begin
      @mutex.lock
      @internalArray == x.ary
    ensure
      @mutex.unlock
    end
  end

Okay, maybe that's ugly.  Hmm.

-- Dossy

-- 
Dossy Shiobara                       mail: dossy / panoptic.com 
Panoptic Computer Network             web: http://www.panoptic.com/ 
  "He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on." (p. 70)