On 23/10/05, robert burrell donkin <[EMAIL PROTECTED]> wrote: > On Sun, 2005-10-23 at 14:56 +0100, Stephen Colebourne wrote: > > This looks interesting. I'll leave the pool comments to a pool > > developer. However, could adding a lot more synchronoization could cause > > other issues with locking and performance? > > probably. however, IMHO an object pool really needs to be thread safe. > i've taken a quick look and think that perhaps it'd be better to fix any > race conditions as the performance price that has to be paid for the > design chosen. opinions?
As Knuth put it "... premature optimization is the root of all evil". And Jackson: Rule 1. Don't do it Rule 2. (for experts only). Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution. [From Bloch, Effective Java, Item 37] It's not only race conditions that might need to be fixed - "Synchronization is required for reliable communication between threads as well as for mutual exclusion." [Ibid, Item 48] He says that modern JVMs have much lower overheads for synchronisation than the early releases, especially if the synchronisation is uncontended, as would be the case for single-threaded access. So I'd suggest doing enough synch to ensure that the user can use all the methods individually without needing to synchronise. Iterators would likely still need external synch (except when running single-threaded). > are there any pool developers out there with time to pick this up? > > otherwise, we could probably do with a volunteer to go through and > analyse these issues. anyone fancy taking a crack at this? > > - robert > > > --------------------------------------------------------------------- > 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]
