By restricting all object data access to a callback mechanism, a Java server can contain all concurrency issues in a single place, making it much easier for you to see if concurrency constraints have been violated.
by Greg Travis
May 18, 2005
ne of the most common errors Java programmers make when they first learn multi-threaded programming is to misunderstand locks. They believe that locking an object prevents access to its fields and methods, when in fact a lock on an object serves only to prevent other threads from gaining the same lock. This confusion, while understandable, can lead to vexing concurrency bugs.
In fact, many concurrency bugs come down to particular data being accessed at the wrong time—usually while someone else is changing it. Concurrency models in general rely on a set of interconnected synchronization zones, spread out over a number of source files. Such designs are vulnerable to "concurrency rot", in which the delicate relationships between different elements become hard to manage as code changes. Wouldn't it be nice if you really could lock an object and keep it all to yourself while you used it?
It's quick, easy and you get access to all the articles on DevX.
This registration/login is to allow you to read articles on devx.com. Already a member?
To become a member of DevX.com create your Member Profile by completing the form below. Membership is free!
ne of the most common errors Java programmers make when they first learn multi-threaded programming is to misunderstand locks. They believe that locking an object prevents access to its fields and methods, when in fact a lock on an object serves only to prevent other threads from gaining the same lock. This confusion, while understandable, can lead to vexing concurrency bugs.
