jaoo - scoop

JAOO Currently at the JAOO, what a great conference and some amazing speakers. The next few postings are observations and notes from the sessions I attended, mistakes and misunderstandings are all my own work. I'll try and include links so you can find out more about the topics as well. Firstly "SCOOP: Concurrent Programming" which was presented by Bertrand Meyer and was part of the concurrency track. I guess no surprise he mentioned preconditions, I do like the idea and often find myself thinking in a 'contract first' way - still not convinced very complex preconditions are manageable, I'd still think it easier write unit tests to express those behaviors. Anyway SCOOP seems to offers a clean and elegant model of concurrency, although still based on ideas we are familiar with. Effectively they do locking at the object level and use method arguments to specify objects over which a method needs to obtains a lock. I like this idea because it's very clear and avoids the horrible synchnoised(lock) I've seen all too often in java code, at the very least we should give these (artificial) lock objects meaningful names. It seems the language (an extended Eiffel) is able to then run this code in a concurrent fashion, I'm guessing there must be a lot of clever math going on in the compiler to avoid deadlock, schedule the locking, etc. It also seems having the locking at the object level is more likely to make us think harder about what should actually be in a class. One thing that did surprise me was the lack of object migration, I immediately found myself thinking of fault tolerance and scaling, I need to read more on SCOOP before jumping to conclusions though. One question which came up was that if we need to block until all arguments of a method are available (i.e. we have the lock on them) is that inefficient. The answer seems to be getting a answer as late as possible and lazy waits. Interestingly Meyer seems against Active Objects, I've certainly seen lots of problems in making the same object reentrant on event callbacks, perhaps a symptom of trying to do an event based architecture while still thinking in request/reply terms.