Re: synchronized using String.intern()



On Fri, 30 Jan 2009, Paul J. Lucas wrote:

Zig wrote:
It will return the same objects for two threads within the same VM. It would obviously not lock the file from access by another process, including another VM.

Yes, I know (and I don't care about other VMs or processes).

Also, I think current VMs implement String.intern by adding unique values to the Permanent Generation heap? Thus, the result of String.intern does not get garbage collected. Using String.intern for many temporary strings has been reported to lead to OutOfMemory errors.

In my case, the number of such strings is guaranteed to be on the order of 1-10, so, again, I don't care.

I think i'd be looking for a way to refactor the architecture so that all access to one of those files went through a single application object. I would then either synchronize on that, or site a higher-level locking mechanism there.

Something like:

class ApplicationFile {
private File file;
private ReadWriteLock lock;
public void addEntryToFile(Entry entry) {
if (!lock.writeLock().tryLock(200, MILLISECONDS))
throw new ApplicationException("timed out waiting to lock file " + file.getName());
try {
ADD ENTRY TO FILE GIVING FILE
}
finally {
lock.unlock();
}
}
public void doSomeOtherLowLevelOperationOfYourApplication() {
// similar to the above
}
// and more methods for the other low-level ops
}

I'd then stick the 1-10 of these that get used in a HashMap, and pull them out and use them as needed.

Even better, rather than passing around strings in the app to identify which file needs to be worked on, i'd pass references to the ApplicationFile instances, to save on the lookup.

tom

--
Only men's minds could have mapped into abstraction such a territory
.



Relevant Pages

  • Re: simplest thread safe pattern
    ... The actual threads in my app are spawned in higher-layer code -- this higher-layer code knows nothing of how data-access is implemented. ... While a thread is executing code inside the specific locked method, all other threads will need to wait until the current thread exits. ... Other methods in the class (even those that are locked in identical fashion) are not affected the lock. ... public void Method1() ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: thread-safety
    ... It supports immediate addition to the consumer's queue, and creation of a repeating timer that will periodicially add to the consumer's queue. ... private TimeSpan _tsExecute; ... // the JobConsumer class while holding it's own lock. ... public void Add ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: simplest thread safe pattern
    ... I hate to be the bad guy, but since you asked for the best way to accomplish it... ... While a thread is executing code inside the specific locked method, all other threads will need to wait until the current thread exits. ... Other methods in the class (even those that are locked in identical fashion) are not affected the lock. ... public void Method1() ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: thread-safety
    ... and I started to use dotnet's queue collection with lock protection. ... private enum WorkerThreadState; ... private object stateLocker = new object; ... public void Start ...
    (microsoft.public.dotnet.languages.csharp)
  • [PATCH 8/10] cxgb3 - offload capabilities
    ... This patch implements the offload capabilities of the ... * normal to get offload packets at this stage. ... Entry lookups and allocations happen ... * under the protection of the table lock, ...
    (Linux-Kernel)