markspace wrote:
> RVince wrote:
>
>> It seems based on everyone's comments (please correct me if I am
>> wrong), that all I really need do is make lockObject a static variable
>
> No, you don't need to make the lock static. No, you don't need to do
> anything from the calling thread.
>
>> from the calling thread. This way, all see it, and there is only one
>> copy that all threads called would be working from. This seems simple,
>
> Even if your class is a singleton, you should still use an instance
> variable, not a static variable.
>
>
>> solid and robust. For example:
>
> I think your code may have got worse.
>
>
>> class MyCallingClass{
>> static ReentrantLock lockObject = new ReentrantLock(false);
>> myCalledThread=newMyCalledThread(lockObject);
>> myCalledThread.t.start();
>
>
> Does this code even run? Can you compile this first and show the output
> in your post, please? I think a lack of a concrete example is really
> starting to hinder the discussion.
>
> What you did here is totally different than your original post. Your
> first post was a synchronized or thread-safe object. That's standard
> enough. Now you have a global, static lock that anyone can acquire, and
> everyone making a particular set of calls has to remember to take the
> lock. This seems several large steps in the wrong direction.
>
> If nothing else, please go with encapsulating the lock into an object
> that does the work for you. That's basic, basic software engineering.
>
I'm with Mark here, especially concerning his last paragraph. Maybe you
should step back a bit, take a few deep breaths, and recapture a high
level view of what it is you're trying to do here. By the way, reading
the Java tutorial on concurrency would be a good idea, and having a copy
of "Java Concurrency In Practice" is even better...but that's an aside.
Concerning Mark's last point, think of the use of ReentrantLock (or Lock
in general) as _basically_ replacing a use of "synchronized". (Similar
replacement semantics occur between java.util.concurrent.locks.Condition
and the Object monitor methods like wait() and notifyAll()).
Running (pun not intended) with that idea, why would you use
"synchronized" (or ReentrantLock) on a block or method? Because you
don't want 2 or more threads executing the code in that block or method
at the same time. These are your callers - don't worry so much about
them right now. Like Mark said, concern yourself at the moment with the
callee class, which contains the method that many threads could invoke.
_That_ is the class that will contain the ReentrantLock (a final
instance variable[*]). Each "synchronized" (no use of that keyword any
more) method will use the idiom you see at the top of
http://java.sun.com/j2se/1.5.0/docs/...trantLock.html.
This should get you back on the right track. You need to logically
understand what it is that's really happening before you start coding in
the synchronization itself. In this particular case, unless I'm missing
something, the concurrency situation is as basic as it gets.
AHS
* This is not a hard and fast rule, but again, think about what it is
that you're doing. You have an output stream that is associated with an
instance of the callee class (my assumption). You want only one thread
at a time to be able to write to this stream. You basically want the
ReentrantLock to exist at the same scope and the same place as the
output stream, hence it's an instance variable. "final" because no
thread should change it.
Similar Threads
