The Multi-Threading Follies, Part Duhh

[Joe \Nuke Me Xemu\ Foster]

"Kunle Odutola okocha.freeserve.co.uk>" <kunle.odutola@<REMOVETHIS> wrote in message <news:3caced95@10.1.10.29>...

> "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
> news:3cacd6d1@10.1.10.29...
> > "Robert Lantry" <mirth@mirthy.com> wrote in message
> <news:3caa56cc$1@10.1.10.29>...
> >
> > > It actually makes a lot more sense if you understand threading to begin
> > > with...
> >
> > What happens when two threads
> > try to do that on the same instance?
>
> Read up on the "lock" statement?.

Idiot. The whole raison d'être of ReaderWriterLock is to allow
multiple threads to simultaneously READ a resource while at the
same time allowing the occasional exclusive WRITE. If the vast
majority of accesses will be READ only, a critical section with
SyncLock would be /exactly/ the wrong approach entirely! Isn't
it amazing how VB.NOT needs special-purpose statements to give
you something a simple little class could do in C++ or even VB?
(Perhaps as part of a shared-memory component in/for VB)

Then there's the overall design of the synchronization classes:
They're completely b0rked! What could these Microsoft cretins
have possibly been thinking? Acquiring a lock should return an
object, and disposing or finalizing that object should be what
releases the lock. That way, should some sod's code eat **** &
throw without explicitly releasing its locks, hopefully the GC
will /eventually/ get around to knocking them off its Finalize
queue, and the application hopefully can recover, /even if the
thread which had leaked those locks hasn't terminated/.

Oh wait, the "optimization" in which objects that are no longer
explicitly referenced in the code are automagically, prematurely
leaked by the JITter would tend to assrape this sort of scheme,
wouldn't it? Thus the need for crapping up .NET languages with
special lock and SyncLock statements, eh?

URL:http://groups.google.com/groups?selm...%40tkmsftngp04

We have here, multiple interlocking cluster-****s... Niiiice!

--
Joe Foster <mailto:jlfoster%40znet.com> Space Cooties! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Kunle Odutola]

"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:3cad085b@10.1.10.29...

> > > What happens when two threads
> > > try to do that on the same instance?
> >
> > Read up on the "lock" statement?.
>
> Idiot. The whole raison d'être of ReaderWriterLock is to allow
> multiple threads to simultaneously READ a resource while at the
> same time allowing the occasional exclusive WRITE.

So who's protecting the ReaderWriterLock instance itself?. Incidentally by
"lock" I was referring to the C# "lock" statement. It's equivalent is
SyncLock in VB. You need it (or something like it) because of this excerpt
from the ReaderWriterLock documentation.....

<quote>
Thread Safety
Any public static (Shared in Visual Basic) members of this type are safe for
multithreaded operations. Any instance members are not guaranteed to be
thread safe.

</quote>


<SNIPPED joe's-opinion-of-what-is-right/>

> We have here, multiple interlocking cluster-****s... Niiiice!

Why don't you write your own joe.foster.threading assembly that uses all
those ideas that you have an MS was too dumb to think of?. VB.NET allows you
to do just that, unlike VB.....

Kunle

[Patrick Steele [MVP]]

In article <3cad940c@10.1.10.29> (from "Kunle Odutola" <kunle.odutola@
<REMOVETHIS>okocha.freeserve.co.uk> <"Kunle Odutola" <kunle.odutola@
<REMOVETHIS>okocha.freeserve.co.uk>>),
> Why don't you write your own joe.foster.threading assembly that uses all
> those ideas that you have an MS was too dumb to think of?

Heh... You'll never see that. I remember one time when Joe was posting
about a "memory leak" that existed in .NET. When asked to show some
code reproducing the error, he responded with his usual "Do you
deny....?" questions. Repeated attempts to get some code from him
failed and the thread eventually died -- sans code.

--
Patrick Steele
Microsoft .NET MVP