> -----Original Message----- > From: guy keren [mailto:[EMAIL PROTECTED]] > Sent: Sunday, March 17, 2002 12:48 PM > To: Tzahi Fadida > Cc: Malcolm Kavalsky; [EMAIL PROTECTED] > Subject: RE: pthreads question > > > > 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)?
Well, i am not going to give code examples, so we'll drop it. better is a relative term. Plus i never used ACE so i can't compare. > > > > 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? I thought I was clear because there is no other meaning for my words then language design. If you also meant design, than by your own words C/C++ and java have a bad design. But I guess u meant code. and its obviously bad to have ur program stuck! :) (though some OSes use this technique on the basis of "infrequent" deadlocks to increase performance). > > > 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. Again i was referring to language design. Since u know, that we are not in the dark ages anymore, and a good language often implicitly handle facilities such as garbage collection, etc and for our topic Java also manages threads natively. I guess its a middle ground as i said, to allow flexibility. While C/C++ do not hanle it natively obviously for maximum flexibility. which again is a tradeoff, like range checking. > > > > > 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. I must disagree here. not having a deadlock Prevents "starvation" in the strict send in the philosophers case. But starvation which is not indefinetly is also a kind of starvation. for example, if 4 from 5 philosophers get access to their plates for a week while they interchangeably release and aquire their sticks. how is that possible? it could be possible if by chance the random time of release and acuire always succeed from either side of the particular 5th philosopher. The thing is, that he will eventually get to eat because the scheme is deadlock free. But i don't think he can hang on for a week. to solve it read ahead about aging... > > > 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. I was referring to synchronize + volatile array. which implies locking and in my previous mail i specifically defined that a process will not enter its critical section unless the volatile array indicates all his future resources for his run in the critical section are free. (which is a very easy thing in JAVA). > > > 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? As you know, linux itself use an aging mechanism. in the simplest case you can define an integer or an array that will indicate LFU. problem solved. > > > > 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). > this is why I appreciate it. The main reason I am bothering to mention JAVA all the time, is because I believe that with the increase in complexity of data and data manipulation in recent years, Simple and straight forward designs are preferable and Java is one of a short list of higher level languages that can help lower costs.(and I am not referring to training because u could claim that today java is a lot more spread than 5 years ago.). C++ will soon be a thing of the past in high level programming, leaving it to middleware and high performance applications. Now that's my opinion/prediction, you might interpret it differently, but that's your prerogative ;) > -- > 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]
