[jcifs] Re: Deadlock in SmbTree.treeConnect()

Ronny Schuetz Usenet.r96 at gishpuppy.com
Wed Apr 23 18:48:58 GMT 2008

> Sure, in theory it can happen with fewer threads. Just as it can with
> your extra locks. It just doesn't seem to happen in practice.

The reason for the extra locks is to avoid the deadlocks, as the 
deadlocks just occur due to the different order of the objects being 
synchronized on. I don't think that you'll see the deadlocks anymore if 
all locks would be obtained in the same order always, which is right now 
enforced by the setupDiscoLock and working well. But I agree with you, 
it is not the best solution.

Please believe me, I've seen the deadlocks in practice :(

> Incedentally, if you look at the throughput of pulling files from the
> same server with 10 threads vs 2 or 3 I think you'll find there's no
> difference. Or, if there is a difference I would not be surprised to
> find that 10 threads is actually slower than using 2 or 3.
> Multiplexing is a feature of JCIFS. Right now, if you push it, it
> will break.

We're pulling/pushing files from/to different shares on sometimes the 
same server. We could of course synchronize these attempts to lower the 
number of concurrently processed files per server, but it is of course 
easier and better to rely on the library than implementing workarounds 
into our application.


More information about the jcifs mailing list