On Fri, 15 Mar 2002, Malcolm Kavalsky wrote:
> >This is the standard "Use qmail instead" reply to "I want to do this with > >sendmail". Perhaps pertinent, but not what the one who asked the question > >wishes to hear. > > I got the idea that the original poster was a young programmer, and > wanted to > warn him before he got started on his journey into "threadland" of the > perils that > await him. The streets there are not really paved with gold ... that's a good motivation. indeed, people who enter multi-threading arena should be mentally prepared for the learning curve. however, it shouldn't be ultimately dismissed the way you presented it. > >I won't comment further, but I'll just say that some of the problems one > >encounters with multi-threading exist in one form or another in > >multi-processing. Furthermore, multi-threading waiting for > >synchronizations can be avoided by using trylock and friends. This will > >require a more complicated design, but is doable. (and there are many > >times similar phenomena in multi-processing). > > This illustrates what I have said, things start getting complicated when you > want your program to work well. You need to develop all sorts of > strategies to combat > situations that you never expected when you started. In the end, I am > not sure that > you would have a simpler design than if you had used processes in the > beginning. this could easily stem from a bad original design. i have written multi-process code for several years (by 'multi' i mean software with few 10s of different processes distributed on several machines), and started writing multi-threaded code about 2.5 years ago. i've written and seen multi-threaded code that's easy to debug and maintain, and i've seen code that is hard to debug and maintain. in general, i agree that for a novice programmer, multi-threading is harder then multi-processing. however, experienced programmers (i'm not talking mega-years of experience) who are _open minded about new concepts_ ( ;) ) find it sometimes easier to write code with threads then without. > In my experience, the initial design phase is simpler using threads, > however after > the program matures, and after many sleepless nights of debugging, the final > implementation is far more complicated than originally designed. that shows the designer was not thinking in a mode prper for multi-threading, and often it implies not using methods such as 'active objects', which aleviate most of the locking problems with multi-threaded code. i know what happens in code that wasn't design with multi-threading in mind from the start (it can indeed go baaaad), and i also know what happens the other way around (problems that look complicated suddenly become much simpler). if you haven't done so yet - i suggest you take a look at ACE (Adaptive Communications Environment) - and in particular at their 'active-object' and 'futures' concepts - this might give you some ideas. > Debugging is much harder since the indeterminism of each execution makes > replication of bugs ( due to race-conditions ) much harder. what _are_ you takling about? the exact same indeterminism occures with multi-processing. each process runs on its own, and they have races in-between them, and they run in a most non-deterministic manner. with multi-threading, its at least easy to stop al threads together (at the same time) - with the support of proper debuggers - although i find myself often debugging with printf (both when doing multi-threaded and when doing multi-process programming). in fat, a good log has proved inaluable for debugging both types of systems. > You can often tell QA > department that you could not recreate their bug report, there is a good > chance > that they will not be able to repeat it, as well. But you are never sure > when this > bug will rear its ugly head. Of course, this can happen in > multi-processing applications > as well, but I do believe that debugging a deterministic process, step > by step is far easier. you mean its deterministic in the scope of that specific process. but meanwhile, the other processes keep on running, and do what they will, further affecting your debugging course. the only difference is when debugging memory corruption problems - and that's where purify, insure++ and boundschecker come into play. and they seem to support multi-threading quite well. > An interesting aside, is that Apache, a prime candidate for > multi-threading , was not > originally based on threads (multi-threading was added into version 2.0, > adding certain problems). i am not sure they chose multi-threading because they considered multi-processing better. they started off from an existing code base (NCSA httpd) and that begun when there was no way to write portable multi-threaded code (because many platforms didn't even support threads, including SunOs 4.X, which was a dominant internet OS back in those days). you may ask yourself - if multi-processing was that good - why did they add multi-threading now, all of a sudden? > Microsofts IISis of course based on threads, and we all know which > server is superior, this is populism - the projects were done by different people, on different OSes, with different goals (apache - write good software with the _features_ we want. IIS - take over the internet server world by leveraging window's market share). taking two specific projects without going into the details and using that as 'proof' for your claims is as bas as proving a theorem using hand-waving - its a tool one uses when they run out of anything better to say ;) also, yes - we know that mindcraft has proved windows with IIS runs faster then linux with apache :P~~ i'm talking about the 2nd test - in which ziff-davis hosted the test and linux people came to tune their part of the system. (ofcourse the etst was somewhat flawed - it served only static pages, that were all loaded from memory, because they used a small set of pages, to avoid having any disk activity during the test). i expect lots of flames regarding the above paragraph. i've enlarged /dev/null to accomodate for exesive data. -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
