[jcifs] Fast cache access patch

[Jan Schlößin]

Michael B Allen schrieb:
> On Tue, Feb 10, 2009 at 11:25 AM, Michael B Allen <ioplex at gmail.com> wrote:

[...]

> Actually there's nothing wrong with the thread-safety of your patch.
> 
> However, the patch is invalid. The purpose of lookupServerOrWorkgroup
> is to query the server and workgroup in parallel. So by calling
> NbtAdress.getHostByName at the beginning, that effectively serializes
> the lookups (and renders one of them redundant in the process). There
> must be two threads to perform the lookups independently so that the
> first to respond can signal the caller to return with the answer.

A yes I see. But the point is that this patch really speed up my
transfer. May be there is a problem with the semaphore if there is a
context switch before a thread passes the line

  synchronized( sem ) {

some other threads could pass

  Sem sem = new Sem( 2 );

So in this case all these threads in between the two lines would wait
until the first one release sem again. For explanation:

In my network there are over hundred windows boxes. And I often have to
gather some thousand files small files (1kB - 5kB) from each. So file
work (authentication, find file, reading attributes, open file, ...)
took a long time compared with the transfer time for each file. To
gather all files faster I start say 20 - 30 threads each for a new peer.
Every thread is calling lookupServerOrWorkgroup() indirectly on every
new SmbFile. When a thread starts looking up its next (IP still unknown)
peer IP a lot of the other threads are likely to sync on sem.

I think it will need further study ...

Jan