Which List should be used, to remove in a thread safe way?

Hello all,

I plan to have a List, where n number of Threads will accessing the List.

When two or more thread trying to remove an equals items from the List, only one of the thread will remove successfully (i,e, remove(Object o) will return true). The rest of the threads will realize remove(Object o) returns false

I wish to achieve this. I know that I can achieve by using :

Collections.synchronizedList(new ArrayList(...))

However, I afraid having the synchronized block will slow down my execution speed. Is there other way, that I achieve the same objective with faster speed? For example, using CopyOnWriteArrayList?

Thanks!

[705 byte] By [KwangHooia] at [2007-11-27 7:06:59]
# 1
Hi; simplay you can use Vector, which is synchronized internally.
GsrCa at 2007-7-12 18:58:18 > top of Java-index,Core,Core APIs...
# 2
> Hi;> > simplay you can use Vector, which is synchronized> internally.Which would not lead to a significant speed improvement as opposed to:Collections.synchronizedList(...)
prometheuzza at 2007-7-12 18:58:18 > top of Java-index,Core,Core APIs...
# 3
@GsrCNo, vector is badly synchronized.A good way is your KwangHooi. I don't know any other that could improve your performances.
ibanna at 2007-7-12 18:58:18 > top of Java-index,Core,Core APIs...
# 4
> @GsrC> No, vector is badly synchronized.> What do you mean by badly synchronized? Could you be a bit more specific as to what's bad about the implementation of the java.util.Vector class?
prometheuzza at 2007-7-12 18:58:18 > top of Java-index,Core,Core APIs...
# 5

Sorry,

I said "badly" because it is synchornized by putting "synchronized" keyword on most of the methods prototypes.

Which equals to synchronizing on "this".

In my opinion, one problem of this implementation is that 2 calls to a get() method will be synchronized wherever they dont need to. (As get() does not modify the vector). [See Edit]

One other is you can synchronize on the Vector's mutex (itself) outside of the Vector's code.

And at last, as synchronizedList is not implemented by a Vector and is more recent than the Vector implementation...

I guess they implemented it in another way for many good reasons...

[Edit]

As i can see in Collections, the synchronizedList is implemented in the same way.

BUT, as the synchronized keyword is not in the method's prototype, we can expect the implementation to be changed a day...

And vector is a kind of old object kept for backward compatibility i guess. (someone can confirm ?). ("As of the Java 2 platform v1.2, this class has been retrofitted to implement List, so that it becomes a part of Java's collection framework.")

@KwangHooi

You can write your own implementation of a List which will not synchronize on the same token for both read/write operations. (but, i guess it could be hard to avoid deadlocks)

ibanna at 2007-7-12 18:58:18 > top of Java-index,Core,Core APIs...
# 6
@KwangHooi: I suggest just writing your application with the Collections.synchronizedList(...). After it's finished you can always re-factor parts of it that are causing performance issues. Maybe there are no performance issues for you to begin with!
prometheuzza at 2007-7-12 18:58:18 > top of Java-index,Core,Core APIs...
# 7
@prometheuzzI would have enjoyed your opinion on my "critic" about the Vector... :(Did i say something wrong ?
ibanna at 2007-7-12 18:58:18 > top of Java-index,Core,Core APIs...
# 8
> I afraid having the synchronized block will slow down my execution speed.But you really have no idea if that is true or not. Don't design based on factors that you know nothing about. Find out first, then redesign if it is a problem.
DrClapa at 2007-7-12 18:58:18 > top of Java-index,Core,Core APIs...