an interesting bug...

This is a discussion on an interesting bug... within the General Discussions forums, part of the Community Boards category; So, I was coding today and banging my head against the wall as usual. I have been trying to multithread ...

  1. #1
    Linguistic Engineer... doubleanti's Avatar
    Join Date
    Aug 2001
    Location
    CA
    Posts
    2,459

    an interesting bug...

    So, I was coding today and banging my head against the wall as usual. I have been trying to multithread my code to take advantage of multi-core processors.

    It turns out I have been leaving a lot of data open and having all sorts of file parsing errors that I hadn't anticipated. I learned about this because threads which read files wouldn't die.

    I guess sometimes learning a new programming concept, though it complicates things, can help you find bugs! Makes me happy... =]
    hasafraggin shizigishin oppashigger...

  2. #2
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,383
    What was the bug, actually?
    One of the things that will never stop to amaze me about programming, is the feeling of achievement even after long periods of frustration. A bug can have me spend a whole day looking at the debugger to the point exasperation. But the precise moment the cause is found and the bug corrected, I always get a strong feeling of accomplishment and all the previous frustration is forgotten.

    BTW, was this just you experimenting? Or is there a reason why you don't want to use some asynchronous I/O library?
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  3. #3
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,584
    ...I learned about this because threads which read files wouldn't die.
    Hehe. That is certainly not a good thing. Multi-threaded programming is still no fun for me and even though I can pull it off there always seems to be one minor thing I miss or forget to protect and the whole thing comes crashing down around me.

  4. #4
    Linguistic Engineer... doubleanti's Avatar
    Join Date
    Aug 2001
    Location
    CA
    Posts
    2,459
    @Mario

    The bug was that in my Word class I use a static TreeMap so I can do comparisions between integer keys instead of Strings, which is much much faster. Worked like a charm in a single-thread model, but failed miserably in a multithread model when multiple threads tried to IO to the map.

    I have thought about another topology where I have a thread which does IO, and then threads which process...

    It turns out there is a lot to synchronize, and I'm at this point 'tightening up' my synchronization to only be around write commands for shared data. Am I right in thinking that the only things that need to be synchronized are when writing to shared objects? And that reading is OK in general from several threads?

    @Bubba

    I had cut my teeth in procedural programming, then OOP (which I still don't feel touch-and-go with, there are a few things I tend not to use...), and now this multithreading business is causing me to grow gray hairs... But, changes in architecture mean this needs to be learned, and I like it...

    I guess what I'm saying is, as I'm sure you older programmers have learned, that this is the first time I can directly see an effect of the changing technology that I feel I need to 'keep up with'. I'm hoping that in the future they make this sort of thing transparent to the programmer... =] It adds a dimension of complexity that makes programming even more of an art...
    hasafraggin shizigishin oppashigger...

  5. #5
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,383
    Quote Originally Posted by doubleanti View Post
    Am I right in thinking that the only things that need to be synchronized are when writing to shared objects? And that reading is OK in general from several threads?
    Depends on the exact nature of what you are doing, but generally speaking threaded IO is to be avoided. Reading or writing shouldn't make a difference. This is so, because, if you think about it, there's really only one path to the hard drive. Threaded reading or writing operations won't make a difference since the disk head will still operate in a sequential manner.

    Of course, I'm speaking of using several threads to read from, or write to, the disk. In case you want a thread to do it while other threads do other processing tasks not related to disk IO, that should be fine as long as it's not complicated. What you want to avoid is the use of multiple threads tasked with reading or writing.

    In any case, whenever there's a need to "multitask" disk access (be it through multiple threads or a single separate thread), you should turn your attention to asynchronous IO instead. These libraries present you with a model that handles exactly the complications presented with synchronization. Most notably the ability to easily define which threads are meant to keep executing, and which ones are meant to wait for disk IO to complete.

    I'm hoping that in the future they make this sort of thing transparent to the programmer... =] It adds a dimension of complexity that makes programming even more of an art...
    You and I mate. You and I.

    Personally I place the blame on the threading model adopted by C, C++ and many other languages. I'm a critic of my beloved language, on this aspect.

    Other threading models exist. Most notably (and the one I always shamefully promote) is the Actor model presented in programming languages like Erlang (see links below). In fact, I've experimented before with the possibility of interfacing my multithreaded programming in Erlang with my C++, bypassing entirely the need to code for C++ threads. Interfaces like Jinterface, tinch++, EPAPI, or Erlang's own erl_nif C library, offer solutions in this regard. But it's all a bit experimental yet and not really advisable for production code... or practical for large and complex projects.

    So, my real hope is that, one day, somehow we realize that the Thread model is bonkers and we are insane for trying to code multitasking this way. Then highly qualified library writers will see to it to abstract the whole thing away from us programmers and develop good quality libraries that present us with other models. My personal vote, the Actor model.

    Links:
    An introduction to the "The problem with threads" paper: Stay Hungry, Stay Foolish - The Problem with Threads | …on Coding | Algorithm.com.au

    "The Problem with Threads" paper: http://www.eecs.berkeley.edu/Pubs/Te...ECS-2006-1.pdf (pdf link)
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Disappearing Bug
    By el-sid in forum C++ Programming
    Replies: 4
    Last Post: 08-16-2009, 12:12 PM
  2. A few interesting tools...
    By Mad_guy in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 03-10-2009, 06:07 PM
  3. gaks bug?
    By Yarin in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 08-31-2008, 02:47 PM
  4. Debugging a rare / unreproducible bug..
    By g4j31a5 in forum A Brief History of Cprogramming.com
    Replies: 18
    Last Post: 08-05-2008, 12:56 PM
  5. ATL bug of CComPtr?
    By George2 in forum Windows Programming
    Replies: 6
    Last Post: 04-07-2008, 07:52 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21