> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of guy keren > Sent: Saturday, March 16, 2002 1:24 AM > To: Tzahi Fadida > Cc: Malcolm Kavalsky; [EMAIL PROTECTED] > Subject: RE: pthreads question > > > > 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 ;)
There are mechanisms, its a matter of using them correctly. impling u can still create deadlocks if you make realy big beginners mistakes, i am not stating that u can completely eliminate deadlocks automagically in JAVA, just that its easily and 'naturally' avoidable in this particular language. > > > 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. Not so, its a matter of weighing performance agains safety. If there wasn't a performance problem, we could ideally create the ultimate design. But since we live in the real world, a bad/good design is a point of view under the circumstances. > > > 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. I know the philosophers problem, and the solution is as i suggested (1 of several), if u first check if ur sticks are free and only start to eat if u hold two of them and in the event u don't u drop the one u hold (or as i suggested wait() Before entering the critical section and be awakened by either philosopher on ur left and right). besides, by tracking ur resources before entering critical sections, u can break circular waits, etc. Although, as i mentioned in my first email, starvation is still a problem u need to solve for urself, cz i don't know what language/library provides an automated mechanism that will prevent starvation while not creating a deadlock. In JAVA 2.0 the notify() solves starvation but can create a deadlock, on the other hand notifyall() can prevent deadlocks but create starvation. I think, though that starvation is easier to deal with from a programmer point of view, because its not hard to setup some simple aging mechanism. > > > > 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). > granted. Just wanted to add that debugging the way u describe is not trivial to most programmers(if i can make that assumption, so i will be cautious on that one). > > > > 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). granted. no contest there. p.s: can u give me an example of a widely used java server, which is an advantage over a C implementation...? > > -- > 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]
