
Signature
[ don't email me support questions or followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e
> > Each collection has its own array and operations can be performed on
> > these arrays concurrently by concurrently executing threads of
[quoted text clipped - 24 lines]
> [ don't email me support questions or followups ]
> g o r d o n + n e w s @ b a l d e r 1 3 . s e
Actually, its more complicated than this...
If thread A reads property P, and thread B writes property P, then
both thread A AND thread B MUST use some form of synchronization. It
is incorrect not to. The java memory model allows threads to have
their own copy of core memory, and it is only flushed during
synchronization. thread B could update P many times, but A isn't
guarantied to see any of it. Worse, it could see the updates in an
unpredictable order, including partial updates etc...
I recommend the book Java Concurrency In Practice.
<http://www.javaconcurrencyinpractice.com/>
It gives you all the details you need to write a robust and correct
multithreaded application.
Mr B - 13 Mar 2007 13:04 GMT
Thanks alot for the response guys. Well what I want to acheive is the
ability for concurrently executing threads to insert records into
various different collections at the same time. A thread to also deal
with displaying the collection at any time to the user, but a snapshot
of the collection at that time, so I understand that this method
should have exclusive access to the collection, so things cannnot be
inserted, and be syncronized so the same method cannot be called by
another thread, breaking up the output with output from another
display thread. If this can be achieved with sychronize aswell then I
will look into doing this, but wouldn't semaphores be safer?
Semaphores that can manage the number of free slots available and
mutually exclusive access aswell? How could sychronize manage manage
the number of free spaces, would a semaphore be used here?
> If thread A reads property P, and thread B writes property P, then
> both thread A AND thread B MUST use some form of synchronization.
Is this not achieved with a mutual exclusion semaphore on the
collection of properties?
Thanks alot for your advice.
Regards,
Daniel
Mr B - 13 Mar 2007 14:50 GMT
Thanks for the response to this post. I am trying to keep the program
as concurrent as possible, whilst keeping it as simple as possible. I
have a few classes that extend the Thread class and I generate
instances of these classes in a Driver class. These classes include
Enter, Remove, Display, for example. The Collection class is used to
store the data these threads will add and remove to, and therefore has
methods which these threads can call to accomplish their
transactions. I tried to synchronize the Display method but it never
seemed to work, and then I realised that it will need to be static. I
then changed it to static, and my mutex, and all data-variables in the
class then needed to be static, can somebody explain I understand that
static means a single instatiation of the method, but why does its
variables also need to static. This won't work for my program as I
need there different Collection class instances to have seperate
arrays for storing their own elements. I'm a bit confised, if anyone
could explain that would be great.
> If thread A reads property P, and thread B writes property P, then
> both thread A AND thread B MUST use some form of synchronization. It
> is incorrect not to.
Does my mutual exlusion semaphore not guarantee this?
Thanks
Daniel
Daniel Pitts - 13 Mar 2007 19:01 GMT
> Thanks for the response to this post. I am trying to keep the program
> as concurrent as possible, whilst keeping it as simple as possible. I
[quoted text clipped - 21 lines]
> Thanks
> Daniel
It guarantees it only if your collection modifying code ALSO acquires
the mutex. Since you snipped that code, I can make no assumptions.
There is a Lock designed for this.
<http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/
ReadWriteLock.html>
This lets any number of Readers acquire a lock, OR exactly one
writer. this is probably what you want.
Or, look into ConcurrentHashMap, This is a thread-safe alternative to
HashMap, and is probably faster than using Mutex of any sort,
depending on number of threads and contention levels.
Hope this helps,
Daniel (also)