[jcifs] Re: Deadlock in SmbTree.treeConnect()
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