UnixSocketChannel#stateLock is not used

[marschall]

UnixSocketChannel#stateLock is not used. It certainly isn't need for things like #isConnected but things like #finishConnect don't look particularly thread-safe. Concurrent access to #state seems to be possible since it's marked volatile.

[headius]

I think you're right. Want to try to help us tidy this up?

[marschall]

Sure. How fancy do you want the solution to be? Options:

1. All state access synchronizes on #stateLock, remove the volatile
2. Like 1. but replace Object and synchronized with a java.util.concurrent.locks.Lock
3. Only synchronize the write access and calls to #doConnect, keep the volatile for reads. It is my understanding that as of Java SE 5 and the new memory model this should be safe (happens-before-relationship).
4. Use a java.util.concurrent.locks.ReadWriteLock

[headius]

I think we'd want to use OpenJDK's implementations of SelectableChannel as our guide, specifically SocketChannel and its sub/superclasses. A read/write lock may be the most robust option, but the API contract calls for a synchronizable lock...unsure how that would work together.

[marschall]

Uhm, the way I read it SocketChannel calls for a synchronizable lock for the configureBlocking and register methods. I don't see a contradiction when some internal state is protected differently.

[headius]

@marschall Sounds good then...proceed however you see fit and we'll iterate on a PR!

[headius]

Thanks, @marschall!