Re: where are my threads blocking problems?

• Previous message: Cam: "RE: aspnet worker process hang"
• In reply to: Jon Skeet [C# MVP]: "Re: where are my threads blocking problems?"
• Messages sorted by: [ date ] [ thread ]

Date: Fri, 17 Dec 2004 16:30:10 GMT

Hi Jon,
I appreciate your feedback. See my comments inline.
Mountain

"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:MPG.1c2cabb052af202f98bada@msnews.microsoft.com...
> Mr. Mountain <mtnbikn@mediaone.net> wrote:
> > Thanks for your reply. It would not really surprise me if you find
problems
> > with my code, but I haven't actually found anything specific. In fact,
the
> > code works well in a lot of different tests. My main concern is the
> > excessively long times reported to complete a method that should finish
in
> > about 41 ms. I don't see how/why StartSession, for example, could take
2300
> > ms on rare occasions.
>
> I can see why it would if an exception were thrown, and you were
> running under the debugger. I can't say I've seen it though.
>
> > In regard to your comments about keepTesting, I don't really care about
> > Main() or keepTesting, or similar fields.
> > keepTesting is only set to false to end the test and I don't really care
if
> > it this field is thread safe because it isn't part of the code that will
> > eventually move into production. I know this field is a crappy hack, but
I'm
> > working under a tight time deadline and I am trying to just focus on the
> > parts of this test code that will be moved into production.
>
> Okay.
>
> I still don't understand what your code was doing though - as I said
> before, you seem (in the previous code - I haven't looked at the new
> code yet) to check whether or not another thread is processing a
> session, but if it is you still do the processing anyway. Isn't that
> against the whole point?

The new code is exactly the same except for the addition of a new check to
validate that it is doing what it is supposed to do.

The code does indeed prevent more than one thread from processing a session
at the same time. However, I think the problem, from your perspective, is
that I named my methods inappropriately. The method name
"CheckForConflictingSession" seems a bit misleading as I am considering your
comments. This method does indeed let processing continue even if there is a
potentially conflicting session. However, it sets the stage for the
StartSession and EndSession methods to correctly deal with a situation where
a conflict could exist. So it might be better to say that this method is
doing some checking, but not actually handling the conflicts. It also
briefly locks on the whole hashtable (sesssionsBeingProcessed). The Start-
and EndSession methods do not lock this collection. They only lock a single
object that is extracted from the collection. This allows a very fine
grained degree of control, which I think is what you have recommended in
your various articles.

I appreciate your input.

I did post this on Google Answers. I offered $50 just for an indepth code
review, regardless of whether any specific threading problems are pointed
out, or not. So if you feel like going thru the code in greater detail,
maybe you can do it thru Google Answers.

Thanks
>
> --
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too

• Previous message: Cam: "RE: aspnet worker process hang"
• In reply to: Jon Skeet [C# MVP]: "Re: where are my threads blocking problems?"
• Messages sorted by: [ date ] [ thread ]