On Sat, 16 Mar 2002, Tzahi Fadida wrote:
> > that _is_ the nature ofdeadlocks. 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 > canstill 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. you're hand-waving again :P~~. can you give _concrete_ examples, and show why they are better then what you have with pthreads (or better - in ACE)? > > 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, wecould ideally create the ultimate > design. its not a matter of weighing anything. either your code is deadlock free or its broken. saying "i won't lock here cause it reduces performance, and i'll hope this list never gets corrupted" _is_ bad design. if that's not what you meant - what did you mean? > But since we live in the real world, a bad/good design is a point of > view under the circumstances. not regarding deadlocks. a design that has deadlocks allowed is bad bad bad bad bad always. its not a matter of tradeoff. its a matter of corrections of the design and/or the code. > > > 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 thecritical section and be > awakened > by either philosopher on ur left and right). naturaly, this is a racy solution - which means, its not a real solution. if you have starvation inherent to the solution - its not _realy_ a solution. and the goal of the philosophers problem is to avoid starvation. that's the main goal. hence, the need for proper locking. > besides, by tracking ur > resources before entering critical sections, u can break circular waits, > etc. not if you don't use any locking _before_ grabbing your resources. > 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. what does aging has to do with this? how will you implement it? > > 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). debugging, per-se, is not trivial for most programmers :) so i think we agree on this one. > > 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, whichis an advantage over a C implementation...? i was talking about application development in general - not about servers for the masses. when you have a server application to develope, that does not need to run too fast, java makes sense for the same reasons you mentioned earlier - safer programming (no pointers), faster development (supposedly, at least), good support for multi-threading and for IPC, etc. and yes - even the 'write once, run anywhere' thing is relevant. its not true - but its almost true ;) (i.e. the code _does_ run on other platforms, with just the need to specificly ahndle software installation, and setup of external resources, such as files, database, etc). -- 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]
