469,270 Members | 1,129 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,270 developers. It's quick & easy.

ArrayList.Synchronized lock both read and write/add, insert and remove ? Is sync needed even at race condition?

Hi,

What does ArrayList.Synchronized really do for an ArrayList?

Is that equal to add lock(this) for all its public methods and properties?
Not just for Add()/Insert()/Remvoe()/Count, but also for Item (this[])?

Normally,do I need sync at all? Isn't that true without sync the program can
run faster?

For example in the master program, I have an ArrayList , each item in it is
a running thread. When the thread starts, it adds itself in, when the thread
ends, it removes itself from the master ArrayList.
Do I need synchronized version of ArrayList. Without synchronize, it can
always add itself in and remove itself, even at a race condition, right? It
will never remove wrong one right?

Thanks for clarify!
Ryan
Mar 27 '06 #1
3 2680
Hi Vadym,

Thanks for the prompt reply.

I have a silly question, what is IMO, "IMO you have to sync access".

Best Wishes,
Ryan

"Vadym Stetsyak" <va*****@ukr.net> ????
news:Ov**************@TK2MSFTNGP11.phx.gbl...
Hello, Ryan!

RL> What does ArrayList.Synchronized really do for an ArrayList?

When you use ArrayList.Synchronized static method it returs SyncArrayList object. This class inherits from ArrayList
RL> Is that equal to add lock(this) for all its public methods and
RL> properties? Not just for Add()/Insert()/Remvoe()/Count, but also for
RL> Item (this[])?

Yes, but lock() is used on the object you've passed to Synchronized method

RL> Normally,do I need sync at all? Isn't that true without sync the
RL> program can run faster?

If your list is accessed from multiple thread then it is preferable to use synchronized access to the list. Yes, it is true that app will run faster as there is no lock overhead, however you should not forget about synchronization when working with
multiple threads.
RL> For example in the master program, I have an ArrayList , each item in
RL> it is a running thread. When the thread starts, it adds itself in, when RL> the thread ends, it removes itself from the master ArrayList.

RL> Do I need synchronized version of ArrayList. Without synchronize, it
RL> can always add itself in and remove itself, even at a race condition,
RL> right? It will never remove wrong one right?

IMO you have to sync access, as removal in ArrayList measn comparing values in the loop. For the loop Count property if ArrayList is used,
without sync access Count value may be inconsistent.
--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com

Mar 27 '06 #2
| Is that equal to add lock(this) for all its public methods and properties?
| Not just for Add()/Insert()/Remvoe()/Count, but also for Item (this[])?

Yes. I would use my own lock instead and a normal array list. The reason
is because normally you want to do multiple operations inside the same lock,
such as Count, Add, Remove. Using synchronize would mean each of those
operations does a lock instead of locking once as you would do with your own
lock. MS has noticed this as well and has not continued with the
synchronize thing in their new collections. If multiple threads will access
the collection, you need a lock. HTH
Mar 27 '06 #3
Hello, Ryan!

IMO = in my opinion :8-)
There is also another variation of this abreaviation
IMHO = in my humble opinion

--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com
Mar 27 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by Eric | last post: by
6 posts views Thread by rmunson8 | last post: by
17 posts views Thread by Ryan Liu | last post: by
6 posts views Thread by fniles | last post: by
3 posts views Thread by =?Utf-8?B?RWl0YW4=?= | last post: by
19 posts views Thread by =?ISO-8859-1?Q?Nordl=F6w?= | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.