strange ultithreaded problem

So, I have an app. (vb.net 2005) that is a multithreading app. and this
application is blocking after some time.
I have a 1-20 threads doing some jobs and after some time (not at the same
place every time and not always), threads are just stopping at some place
(all of them on the same place).

There is an object that are using all threads (not the same object, but same
type of), and these threads are blocking on following part of code:

_
Public Function FullLocalName(ByRef vSites As cSites) As String
If Not vSites Is Nothing And _SiteId > 0 Then
If _refId = 0 Then
Return vSites.Site(_SiteId).SiteHeader.FolderName &
"photos\" & _Id.ToString & ".jpg"
Else
Return vSites.Site(_SiteId).SiteHeader.FolderName & "photos"
& _refId.ToString & ".jpg"
End If
Else
Return vbNullString
End If
End Function

this function is being called at the place where threads are blocking...
but, to emphasize, they are not blocking on this part at a first pass, but
after 2-3 hours of working and passing through it for many many times.
Altough, there are no needs for putting Synchronized before a function, I
putted there because I though that it needs it.
also, all variables with prefix "_" are local/private variables (also used
in other properties/subs/functions of that object).

does anybody have some anwser for that?
I'm becoming a desperate since I'm trying to fix it 2 weeks

Re: strange ultithreaded problem

It sounds like a deadlock in a rare scenario (thread race?)... so - what
happens inside Site(...), SiteHeader, FolderName, etc?

For example, suppose that Site(...) also takes a (different) lock: if thread
A has the Site lock and wants the lock for the code shown, and thread B has
the thread for the code shown and wants the Site lock, then A and B are
deadlocked. Every other thread that tries to obtain either this *or* the
other lock is going to get blocked.

Marc

Re: strange ultithreaded problem

what should be solution?
should these deadlocks just solve themself or there is some 'best practice'?

"Marc Gravell" wrote in message
news:%23aQltQBlIHA.2368@TK2MSFTNGP03.phx.gbl...
> It sounds like a deadlock in a rare scenario (thread race?)... so - what
> happens inside Site(...), SiteHeader, FolderName, etc?
>
> For example, suppose that Site(...) also takes a (different) lock: if
> thread A has the Site lock and wants the lock for the code shown, and
> thread B has the thread for the code shown and wants the Site lock, then A
> and B are deadlocked. Every other thread that tries to obtain either this
> *or* the other lock is going to get blocked.
>
> Marc
>

Re: strange ultithreaded problem

I now changed something in my app., but it's still the same.
Before calling property from that object, I create a separete, cloned
object...
but it's still the same..

it looks like it is the problem in part:
vSites.Site(_SiteId).SiteHeader.FolderName

how could I prevent from deadlocks on properties?


"Marc Gravell" wrote in message
news:%23aQltQBlIHA.2368@TK2MSFTNGP03.phx.gbl...
> It sounds like a deadlock in a rare scenario (thread race?)... so - what
> happens inside Site(...), SiteHeader, FolderName, etc?
>
> For example, suppose that Site(...) also takes a (different) lock: if
> thread A has the Site lock and wants the lock for the code shown, and
> thread B has the thread for the code shown and wants the Site lock, then A
> and B are deadlocked. Every other thread that tries to obtain either this
> *or* the other lock is going to get blocked.
>
> Marc
>

Re: strange ultithreaded problem

No; deadlocks don't solve themselves.

The best practice is to always aquire locks in the same sequence; that way
all that happens is that the competing thread gets blocked for a few ticks.
But threading is complicated and I don't want to lead you down the wrong
route without any real idea as to what might be happening in the other code.

Another pragmatic approach is to use timed locks - i.e. try to aquire a lock
for (picking a number at random) 5 seconds before giving up. You can't do
this using the attribute version, but if you use explicit locking you can
use:

if(!Monitor.TryEnter(syncLock, 5000)) {
throw new TimeoutException();
}
try {
// your code
} finally {
Monitor.Exit(syncLock);
}

(there are ways of making this tidier and easier to re-use...)

etc - that way you might get the occasional exception, but things should
rectify themselves as they release the locks as the exception bubbles.

One possible approach is hardcore debugging when it hangs... see what each
thread is doing and try to spot the deadlock. Things like sos and windbg,
but not for the faint hearted. Not something I would attempty lightly...

Marc

Re: strange ultithreaded problem

Deadlock was just one suggestion that might fit the symptom. I can't really
tell much without knowledge of what the other code mentioned does,
specifically relating to locks.

Marc