> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of guy keren > Sent: Saturday, March 16, 2002 12:21 AM > To: Tzahi Fadida > Cc: Malcolm Kavalsky; [EMAIL PROTECTED] > Subject: RE: pthreads question > > > > On Fri, 15 Mar 2002, Tzahi Fadida wrote: > > > Well, i am not so savy about threads as most people here, > > its ok, neither are most people here, to bgin with ;) > > > but i think my opionion is middle ground. I think that threads should > > not be used on C user applications as is, because of the > > low level implementation of threads and mutexs there. Instead if you > > realy need threads you should use some library that simplifies things. > > in many situations it indeed makes sense. that's why i mentioned ACE, as > such a library (http://www.cs.wustl.edu/~schmidt/ACE.html). > > > A textbook solution would suggest using "Monitor" objects. In essence, > > the cost for performance using low level impelementations is indeed to > > high. > > err, what? what kind of performance are you refering to? performance of > the code (can't be - it'll be a high cost of the program writes bad code, > but that is the case when writing non-threaded code as well)? or are you > refering to the performance of the _programmer_? :) I was reffering in both cases to the implementation of the threading operation, otherwise we wouldn't have that problem ;). when you use objects, you add increasing instructions to the implementation in serveral way. I guess it really depends on the kind of code u write. if the added instructions and indirect addressing is insignificat to u, then its not a problem at all. (mind u, the monitor scheme uses objects to sperate critical sections). And.. of course the if u use java, the JVM is an added overhead.
> > > If performance is not your main requirement, i suggest you use > > JAVA 2.0 code, which handles threads very well, using behind the scene > > objects locks and calls to notify() as a variation to the > > singal-wait/signal-continue scheme. This would prevent any deadlocks > > how? what if one 'syncronized' method calls another in a different class, > and that other object is also synchronized, and calls the first one? how > does java handle this? in theory, it should deadlock. if java recognizes > this and throws an exception - the deadlock is not 'prevented'. it is > 'reported' (which is good). and its the kind of exception that cannot be > dealt with in runtime - if you could, you'd write the code without > introducing deadlocks in the first place ;) Well, if you are trying so hard to make a deadlock, i am sure we can find a way to acommodate u :). but seriously, u can make a deadlock if u so insist, but it would only be by a realy bad design. besides, u can alway just define a volatile array of bits that will indicate if an obeject is in its critical section, and thus any object trying to enter its critical section will check if its set of resources is free and if not he will just call wait().(which is better than a spinlock, unless u r directing for smp). and on exit just notifyall() will be the safest. no more worries. Simplicity at its best. > > > (but not eliminate starvation completely, actually thats your only > > concern :) and would simplify debugging, > > java - simplify debbuging? these things don't go well together. java > environments are noturious for having slow and annoying debuggers, to the > level that many people prefer using println-s instead of launching te > debugger. > I meant that, by not falling for the begginners (and intermidates mind u) of c/c++ pitfalls, which usually are the cause for the debugging. as for the tools, thats a problem, i know. but if u don't have many bugs, and u already use printf in c/c++ for thread debugging then i think its an improvement. > > not to mention the safe environment you are using. But again, you will > > loose performance. > > there's a price for everything. but that said, indeed, threading in java > seems to come up pretty cheap. ofcourse, that's relevant if you can afford > using java. Well, thats Another aspect. I think that if u are a good designer/programmer u will use the best tool for the job, and not just stick to "what u know". > > -- > 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] ================================================================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]
