Event potential concurrency issues

[mighe]

Event class has some potential concurrency issues.
Event#set? was not synchronized, causing inconsistent visibility under happens-before based memory model (like JRuby and Rubinius)
Event#wait was using an array to store enqueued threads and Event#set woke up them: a ConditionVariable is best suited in those cases and solves some check-then-act issues of the original version

All test are still passing

[coveralls]

Coverage remained the same when pulling 892bf83 on mighe:master into fffd747 on jdantonio:master.

[mighe]

I made a noob mistake, the second commit was for another pull request...
I've started to refactor a little tests to make them faster, avoiding multithreading when it's not necessary

[jdantonio]

I apologize for not looking at this pull request earlier. The past several days have been very busy both at home and at work. I greatly appreciate your help. I don't entirely follow your last comment. Is this PR ready to go or are you still working on the refactoring?

[mighe]

This PR is ready, in the next days I'm going to improve some other classes and refactor some other tests.
I prefer to commit immediately this first test refactor to allow everyone to contribute.

[jdantonio]

Interesting. I expected this to raise a LocalJumpError, which is the normal case when using return within a block. But I've tried it in several version of MRI and it works. So I've learned a new trick with Mutex.

[ghost]

I think return always works when there's a method context somewhere up in the stack.

[jdantonio]

Thank you for the time and effort you have spent on this. The reason I didn't synchronize the @set variable in the places you noted is that I expected the access to be atomic and not in need of locking. You'll find that idiom used in several places in the gem. I'll make sure to fix them as I find them.