Prev: appropriate class variable usage?
Next: Must declare the scalar variable "@myDB@"
From: Peter Duniho on 3 Jun 2010 01:14
Hector Santos wrote:
> [...]
>> Hector, you have completely missed the point of the code example, both
>> in terms of what things in the code example are important, and in
>> comprehending how the example actually works.
>
> Really? I think you are assuming too to be saying that.

I'm not assuming anything. I'm just looking at your replies.

> [...]
> Its an important concept to not mix up SLEEP with ACTUAL THREAD WORK
> when it come to system stabilization.

Sure, but there's nothing about my example that does that

> [...]
>> It would have been nice if you'd actually tried adding that code
>> yourself. Had you done so, you would have seen that it has no effect
>> on the outcome of the code, other than to delay it of course.
>
>
> I did. This following illustrates the contention issue with count as I
> described.

No, it doesn't. I stated several times that the BackgroundWorker
depends on a GUI thread (actually, any thread with a
SynchronizationContext, but in practice this is almost always a GUI thread).

Your example is a console application and as such is completely
irrelevant to my code example and my comments.

Pete
From: Peter Duniho on 3 Jun 2010 01:19
Hector Santos wrote:
> The point is that a little testing yourself would of shown that the
> using the count variable was not a good idea.

Please go back and read my posts more carefully. You are not paying
attention.

> I naturally saw it even for I tried it to prove it was wrong because as
> you indicated, in the world real there would be "real work" not the poor
> man's sleep (which isn't any kind of simulated work whatsoever). This is
> common mistake in thread designs.

There's nothing about the call to Thread.Sleep() in my code example that
has anything to do with the correctness of the code. You can put
anything you want in the DoWork event handler, and the code works just
as well.

> But your example had a bug as I illustrated.

There is no bug in my example.

>> I hope that you will go back and review the code example more carefully.
>
> I did even before I posted. But only tried it because it was obvious
> there would a thread contention issue.

It is clear that you still have not sufficiently reviewed my posts. You
still misunderstand the point of the code example.

> I doubt you even know which a common mistake you showed. If you want to
> be respected, then show some respect yourself.

There is no mistake in my code. It works fine in the context in which
it's intended to be used.

>> In particular, knowing that the BackgroundWorker events, except for
>> DoWork, always get raised on the same thread that created the
>> BackgroundWorker instance (assuming that thread is one with a
>> SynchronizationContext, such as a normal, Forms GUI thread) is
>> critical in understanding why the code example I posted is correct.
>
> You see, you assumed that I was naive about thread, GUI designs or
> designs in general

I made no such assumption. I made an _observation_ that you have failed
(and still continue to fail) to read my posts carefully enough to
understand the point of the code example.

> I seriously doubt you can match my expertise in this
> area.

I'm not interested in a pissing match. You go do that on your own. All
of my statements are strictly about factual matters that can be easily
resolved simply by running the code.

But: you do need to pay attention. Until you do so, you will not have
any idea what I'm talking about.

Pete
From: Hector Santos on 3 Jun 2010 02:19
Peter Duniho wrote:


>> But your example had a bug as I illustrated.
>
> There is no bug in my example.


You're in denial. I appreciate your input, but anyone worth his salt
will see that that using a loop limit variable with internal local
scope change is asking for trouble and would be contention in a real
application using that piece of code. Sleep or not sleep, I saw it
immediately. Its extremely common to see that sort of thing with
inexperienced developers in thread designs - ON ANY SYSTEM. But with
that latter point, I gave you benefit of the doubt thinking maybe the
..NET compiler translated it as a constant, after all, it is a p-code
compiler. That was not the case here and the simply injecting of one
line sleep (your idea of simulated "work" when here is no work at all)
proves the case. When there is real work, you have your classic
contention issues creeping up. That could of been anything.

I'll leave it at that.

--
HLS
From: Peter Duniho on 3 Jun 2010 02:49
Hector Santos wrote:
> Peter Duniho wrote:
>
>
>>> But your example had a bug as I illustrated.
>>
>> There is no bug in my example.
>
> You're in denial.

You are wearing blinders.

> I appreciate your input, but anyone worth his salt
> will see that that using a loop limit variable with internal local scope
> change is asking for trouble and would be contention in a real
> application using that piece of code.

I have explained numerous times why that is not the case.

> Sleep or not sleep, I saw it immediately. [...]

You saw what you wanted to see, because you apparently care more about
your criticism of me than technical accuracy.

If and when you ever go back and read my posts with the care they
deserve, you will see how you are mistaken about your assessment of the
code.

Pete
From: Hector Santos on 3 Jun 2010 07:10
Peter Duniho wrote:

> Hector Santos wrote:


>> I appreciate your input, but anyone worth his salt will see that that
>> using a loop limit variable with internal local scope change is asking
>> for trouble and would be contention in a real application using that
>> piece of code.
>
> I have explained numerous times why that is not the case.


And I explained three times now that you produced a bad example of
thread synchronization.

>> Sleep or not sleep, I saw it immediately. [...]
>
> You saw what you wanted to see, because you apparently care more about
> your criticism of me than technical accuracy.


Exactly!

But if I am critical of you, it is your attitude to believe everyone
is naive to extend and provide information that wasn't required.
Again, all you showed here was the anonymous function - thats it!!
Everything else was already known since the annals of preempted OSes!

> If and when you ever go back and read my posts with the care they
> deserve, you will see how you are mistaken about your assessment of the
> code.

Peter you said nothing but what you wanted to point out believing it
was important, yet it was trivial to the question. It added nothing
beyond extracting two things only:

- Your example of using anonymous functions here, which was good,
- but nonetheless, also YOUR BUG!

And that was simply by eyeballing it and then verifying what would
easly BREAK IT - and yet you went on a MAJOR ASSUMPTION that I didn't
try your code, and you went on with that incorrect assumption. The
fact is you got a BUG and you should be MAN enough to admit.

Everything else was trivial information which was (2nd time I told you
this) was not being asked for. You need to stop that. Do it with
others, not with me. The other fellas were to the point in replies.
You acting like everyone here is stupid. What you indicated was
nothing new NOR what was asked for. You need to stop that.

--
HLS
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: appropriate class variable usage?
Next: Must declare the scalar variable "@myDB@"