A small truth to make our Life 100% successful.......... If A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Is equal to 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Then H+A+R+D+W+O+R+K = 8+1+18+4+23+15+18+11 = 98% K+N+O+W+L+E+D+G+E = 11+14+15+23+12+5+4+7+5 = 96% L+O+V+E=12+15+22+5=54% L+U+C+K = 12+21+3+11 = 47% (None of them makes 100%) ............................... Then what makes 100% Is it Money? ..... No!!!!! Leadership? ...... NO!!!! Every problem has a solution, only if we perhaps change our "ATTITUDE". It is OUR ATTITUDE towards Life and Work that makes OUR Life 100% Successful.. A+T+T+I+T+U+D+E = 1+20+20+9+20+21+4+5 = 100
Sunday, September 11, 2005
Long time blogging.....its high time now "I'am back to hack". Was following a lot of lkml threads these days to garner some intriguing suff. Just found 'KLISTS', these datastructures are highly consistent across the asynchronous processing within the kernel (basically from interrupts from the devices as well as software interrupts).
Ok let me put this in much lucid terms... 1. I have some data to be shared across process's (not threads). 2. This shared data is accessed asynchronously. We get this type of context typically in telecom applications ( I recall from my experience from moto****). They have a unix based system, with several process's running each communicating with each other.
Ok talked a lot about the problem so whats a unix way of solving it. BTW way the data should be consistent and pocess the ACID (Atomic .....dont remember :-p) behaviour i.e a typical transcational behavior, basically the solution should'nt be error prone to race conditions occuring due to asynchronous behaviour within the process's. So how do you architect this kind of applications?
Ok let me give you some really shoddy professional solution which MOTOSHIT has sold to _NEXTEL_ (being soooo dump bought it from moto***a). 1. Moto***a had a real dumb soultion, to make sure that the data is consistent across the process's they seem to use a DATABASE :)).... 2. I have seen code which tries to access a shared variable as a row in the database table. 3. They just dumbly put every shared suff in the database...to make sure that the data is having ACID properties during the modification of the data by these asynchronous process's. 4. And more ludicrously they buy a database from a shoddy database vendor informix....and just heard that they are lobbying for support form IBM for this outdated product. really amazed by the quality (the romantic quality form zen and art of motorcycle maintenance :-p) of the approach to this problem. After knowing about klists I just felt that kernel which also has asychronous stuff inside does it in a much smarter way using KLIST. (KLIST is worth a reading please use the link above).