[jcifs] Re: Deadlock in SmbTree.treeConnect()
Michael B Allen
miallen at ioplex.com
Wed Apr 23 20:46:34 GMT 2008
On Wed, 23 Apr 2008 20:48:58 +0200
Ronny Schuetz <Usenet.r96 at gishpuppy.com> wrote:
> > 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
Several people have made that claim. And after looking at their code I
could always find a hole.
>, 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 :(
Ok, let me qualify that with "good" practice.
But yes, using 10 threads or 100 it's a bug and it should be fixed. But
there's a right way to fix it and adding more locks isn't the right way.
> > 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.
Absolutely agreed. The library should be able to handle any number of
threads. It needs to be fixed but unfortunately I don't don't have the
luxury of doing much for free or Free anymore.
Michael B Allen
PHP Active Directory SPNEGO SSO
More information about the jcifs