On Sat, 16 Mar 2002, Tzahi Fadida wrote:
> > 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 inruntime - 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 :). that _is_ the nature of deadlocks. show me how java's mechanism help prevent deadlocks, please. give a concrete example - talking in the air and hand-waving are not acceptable proof techniques ;) > but seriously, u can make a deadlock if u > so insist, but it would only be by a realy bad design. deadlocks are _always_ a sign of bad design. in any language. > 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. this is not something that rpevents _deadlocks_. deadlocks, by their nature, cannot be solved by 'waiting'. do refer to the dining philosopheres for a hint. > > 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 preferusing 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. i didn't say i don't use a debugger at all. i still use it for quite a few problems. just not for the hard synchronization problems ;) (but i still can use it to debug deadlocks, by attaching to the deadlocked process and viewing the stacks of all threads. and also to identify crashing matters, by viewing a core dump with the debugger. true, i won't get code dumps with java unless i realy try hard enough). > > > 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". when i said 'if you can afford to use java', i didn't imply 'if you can afford learning java'. i refered to 'can afford' in overhead (both space and time), in ability/need to use specific 3rd-party products, etc. and if you like slagish GUIs ;) (java seems to make more sense on the server side, it seems). -- 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]
