Hmm..are you sure that simply relying on "atomic" behaviour is what you want here?
I'm not an expert on java's "memory model", but suggest you give some serious thought before removing any "synchronized" keywords. As I understand it, "atomic" simply means that no two threads will ever see intermediate values of the variable as it changes. eg for a 32 bit int (made of 2 16-bit words), you can never see a state where one of the 16-bit words has been updated but not the other. Example: an int = 0x0000FFFF, add 1. No thread can ever see the low word roll over to all zeros before the high word rolls over to 0x0001. It says nothing about whether other threads will see the new value, or an old cached version of the value. That is what synchronized or volatile keywords do (see also: "memory barrier"). In practice, you will never see a problem on a single-cpu machine; therefore any unit tests checking for thread-safety will never fail on a single-cpu machine, but will on a multi-cpu machine. Example: thread 1 on CPU 1 reads an int, and it is cached in the cpu's cache. thread 2 on CPU 2 reads the same int, increments it, and writes it back to memory, without using synchronized/volatile. thread 1 on CPU 1 now increments its *cached* version & writes it to memory. result: a "missing" increment. With synchronized or volatile, when thread 2 writes to memory, the cache of CPU1 is forced to invalidate the cached data containing the written address. When thread1 tries to access that variable again, it therefore is forced to fetch the new value from memory. The above should be taken with a grain of salt - I haven't got time to double-check this with the java specs at the moment. Hope I'm not misleading you.. Regards, Simon On Thu, 2003-08-14 at 09:15, Dirk Verbeeck wrote: > _numActive is an int so the synchronized block wasn't needed. > But the extra "synchronized" is in the case where a new object > has to be created and not in the critical "get from pool" code path. > > All the success code paths have now one synchronized block. > I'll leave it as is for now. > > Dirk > > > David Graham wrote: > > >--- Dirk Verbeeck <[EMAIL PROTECTED]> wrote: > > > > > >>The pool manipulation was synchronized, only the isEmpty() test is not. > >>I didn't realize that _numActive++ should be synchronized, I thought the > >> > >>++ operator was atomic. > >> > >> > > > >The datatype the operator is applied to is what matters. Assignments to > >ints are atomic, assignments to longs aren't because they are 64 bits. > >So, if _numActive is an int, I don't think it needs to be synchronized. > > > >David > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
