The Multi-Threading Follies, Part Duhh


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 3 of 3

Thread: The Multi-Threading Follies, Part Duhh

  1. #1
    Joe \Nuke Me Xemu\ Foster Guest

    The Multi-Threading Follies, Part Duhh

    "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!



  2. #2
    Kunle Odutola Guest

    Re: The Multi-Threading Follies, Part Duhh


    "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




  3. #3
    Patrick Steele [MVP] Guest

    Re: The Multi-Threading Follies, Part Duhh

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center