Slashdot Mirror
More Effective Use of Shared Memory on Linux
An anonymous reader writes "Making effective use of shared memory in high-level languages such as C++ is not straightforward, but it is possible to overcome the inherent difficulties. This article describes, and includes sample code for, two C++ design patterns that use shared memory on Linux in interesting ways and open the door for more efficient interprocess communication."
some1 should tell the authors to rtfm.
$ man shm_open
Bogus
ha I feel the same
There is a great C++ library for shared memory support: SHMEM. It can place complex objects and STL-like containers in shared memory. And it is crossplatform (POSIX and Windows are supported).
And it will soon (hopefully) be a part of Boost!
No, but I think reading about ownership policies and why they almost always make GC unneccessary must be compulsory.
Imemcached is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.
Unix shared memory paradigm has been around for a long time. There is no need to
re-invent the wheel. BOOST has something, ACE has something, The person that posted
this article should be modded redundant permanently.
More Power to you, back in college my Profs. touted C++ as the shining example of OOPness, curse them I say
Yup they released it and it sucks. Although somewhat related, a distributed object cache is a solution to a totally different set of problems. Why mention it here?
In fact, forget it; just use an actual OO language instead.
C++ is an actual Object Oriented language, which is of course half the problem.
If you mean a pure OO language like Java, in which everything is an object except for primitives and it takes ten classes and wrappers just to read a file, well then C++ isn't exactly an Object Oriented language as such. Perhaps you mean Smalltalk or the like.
I tell you what though, C++ is still around after all this time. With all the hype surrounding Java, Perl, C#, Python, etc, etc, etc C++ programmers are still there beavering away with the god awful sytax Stroustrup left them with. Even after all the improvments, all the innovation and all the additional research into computer languages, for a hell of a lot of tasks, there is really no real alternative to C++.
I don't say this as a C++ fanboy, even though I am "somewhat" fond of the language when it is used properly, and not in garbled and unreadable line noise. I say this simply as a statement of fact. There is still no successor to C++.
I don't want garbage collection so much as I want a cleanup and rationalisation of the syntax. GC would be nice, but forcing more readable code would be even better.
May the Maths Be with you!
I suppose everything marked const could be shared.
A 10 fold speed improvement in switching context can be done by avoiding OS calls for semaphores and customizing a set of calls for as many comsumer-producers as needed.
This avoids using any special opcodes or inneficient cache line flushes.
As long as shared memory is cache coherent, even multiple cpus will work with dekkers 1965 algorithm.
Here is the complete classic code for one cpu of a dual cpu design system or a dual thread setup
amazing! unbelievably fast. In fact is optimal.
Its best if the flags are allocated in their own cachelines, so perhaps pad to 32 bytes on PowerPC for example, and other CPUS might use as few as 16 byte cachlines. This avoids contention and increases coherency for rapid read-writes.
Add Dekkers mutex as I described and the speed of transactions per second will make your head spin in disbelief even in pathological situations
How many people know about this? Nobody! I never read about it anywhere. I invented it myself years ago, before I discoverred this year it was called Dekkers, and Dekker beat me to it in 1965. I tried unsuccessfully, verbally, to get a Phd in comp Sci with embedded management experience to believe me it is 100% sound.... argued for 40 minutes. The guy never had a clue. No wonder that his company's stock is down over a couple billion in market cap since the argument.
Lets not forget the past. Some algorithms are worth remembering.
Anyway, old stuff. Wake me up when you start talking about the newer tricks with shared memory.
Mostly because it allows sloppy, C-style, programming which is easy. It also leaks like a sieve most of the time and has all the security problems seen in C. It doesn't HAVE to but its design means that it does. And it's ugly as hell.
Easy programming languages always hang around longer than they're needed because most programmers, sad to say, are uninterested in quality and very interested in meeting deadlines.
There is still no successor to C++.
That may be true, but it doesn't make C++ any better.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
For concurrent applications, it is hard to beat Reppy's CML.
http://portal.acm.org/citation.cfm?id=113470
In particular, the things you synchronize on are first-class. Also you can speculatively send/receive things. Normal "select" is only for reading. You don't have to manage your memory either.
There are other concurrent languages, but CML is nice in that it has a formal semantics, so unlike typical languages like "C", "C++", Erlang or Java, a program has a meaning other than "whatever the program does when I run it."
You can implement the primitives of CML in your favorite higher-order language, so you don't have to be limited by ML. That's what's in Reppy's book.
A proper implementation can achieve speeds that are about 30x faster than pthreads for typical tests like "ping/pong".
http://www.thebricktestament.com/the_law/when_to_
Quite a few years ago, there was a brief popularity of something called VRAM (video ram) that had memory cells specifically designed with one input line and TWO output lines. The idea was that the part of the hardware needing to construct an image for the screen ONLY needed to read memory, while the system responsible for creating the image needed both read and write access. Ever since then, I've wondered why they don't use this kind of memory in multi-processor systems, for communication between processors, such that Processor A has read/write access to a block of VRAM, to give info to Processor B (it has read-access only), while Processor B has read/write access to a different block of VRAM, to give info to Processor A (it has read-access only).
I consider the backwards comparison to be good C style. It turns a certain broad class of typo from a silent logic error into a compiler error. How many times have you seen
if(x = foo() != -1)
when the programmer meant
if((x = foo()) != -1)
?
If you write your comparisons with the constant first, the compiler will tell you. In particular,
if(-1 != x = foo())
results in a compile-time diagnostic. It's not about "being unfamiliar with C++ syntax". Quite the opposite, someone who writes that way is so familiar with C and C++ syntax that they know how to avoid the common mistakes without batting an eyelash.
It's always a long day... 86400 doesn't fit into a short.
in my above example i noticed slashcode converting some single ascii space white space into
... the source code is correct
AMPERSAND POUND-SIGN 160 SEMICOLON
just swap those back to spaces.
"POUND-SIGN" is defined as octothorpe, not pound-sign the english monetary unit glyph
I would have typed OCTOTHORPE above but i was just letting usa people understand a little more clearly
anyway ignore the AMPERSAND POUND-SIGN 160 SEMICOLON
i wanted to post this earlier, but slashcode crap makes me wait FOREVER to post a correction! What crap. its been 6 minutes and it says "Slow Down Cowboy! It's been 6 minutes since you last successfully posted a comment" I wonder why engineers like me even bother trying to help out on slahdot anymore.
Doesn't MS code use CWhatever? I guess the author is coming from a Java background (I for Interface).
BTW, the very first file is not valid C++: All identifiers which contain double underscores are everywhere and under all circumstances reserved for the implementation. This also includes __COMMON_H__. Change it to e.g. COMMON_H to get valid C++.
Well, at least his main function returns int.
The Tao of math: The numbers you can count are not the real numbers.
I consider compiling with -Wall good style, which warns you when doing an assignment used as an expression. if ((a = 1)) supresses the warning, assuming the coder knows what he's doing.
This is your sig. There are thousands more, but this one is yours.
Almost never... since any half decent compliler will spit out a warning at least (and no shipping code should compile with warnings).
The programmer actually meant:
The Tao of math: The numbers you can count are not the real numbers.
Java, in which everything is an object except for primitives and it takes ten classes and wrappers just to read a file,
Eh?
File inputFile = new File("temp.txt");
FileReader in = new FileReader(inputFile);
Or if you want to use the new IO library from 1.4 which gives you memory mapping and locking on sections of files,
FileChannel in = new FileInputStream("temp.txt").getChannel();
Being bitter is drinking poison and hoping someone else will die
I'm surprised no-one has mentioned Solaris Doors. Doors is an IPC mechanism whereby the first process (client) can hand off any residual time in its timeslice to the second process (server) resulting in short IPC calls running much less time as there is no discarded timeslice time and no wait for the server process to be scheduled (since it uses the client's timeslice).
Too many people here are willing to make inane useless comments about honest work efforts. If you have a better way, offer it. If you merely want to say something nasty about someone else's work, save it for the coffee house.
"If all the American people want is security, let them live in prisons." Eisenhower
"Now let's look at using shared memory and caching of events for interprocess communications. If the events are cached within the shared object, they can be fired later. The receiving process will have to query the shared object for events. Thus, by sticking to a synchronous model, interprocess communication can be achieved. This is the motivation behind developing the following design pattern."
Que? How is that different from an asynchronous message event que? I think they've misused the word synchronous. Presumably the calling process is not waiting for the return from the process it called, so the two processes are running asynchronously. So this is just asynchronous event message passing.
If you mean a pure OO language like Java, in which everything is an object except for primitives ....
Your statement is contradictory. All types are objects in a pure OO language. Yet Java's primitives are not. Thus Java is not a pure object oriented language.
Cyric Zndovzny at your service.
People who think they always need to "new" objects in C++ have spent way too much time using Java.
Here's another hint -- pass objects to functions as const references:This way, a copied object isn't allocated for the passing (no memory at all is in fact allocated). The biggest drawback is you can only call "const" methods on the object, but this is outweighed by not using pointers. Not that I don't like pointers, they just increase the complexity and should be used prudently. And as my
"Save the whales, feed the hungry, free the mallocs" -- author unknown
That's funny. This was one of the first synchronization algorithms we learned in my operating systems class.
That everything is an object in Java except for the primitive types are such a cop out by Sun. Think of all the hacks that result just from that. In Smalltalk, everything is an object even the primitive classes!
As for why C++ is still being used, it is a more type-safe C at the very least. It is nice to be able to do function overloading and declare variables anywhere. And once one gets past the horrible syntax, amazing things can be done/achieved with C++ templates.
> How many people know about this? Nobody!
Only those, which know of Futexes.
"Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
Can someone explain why parent is +1 insightful and not -1 troll? (or flamebait)?
Or in C
FILE stream = fopen( "crt_fopen.c", "r" );
The only way to read the filechannel is a bytebuffer. Has anyone ever used them? I had to once and it sucked....
FileReader (or BufferedInputStream) are still awkward because tehy use byte and string arrays. Those really are hard to work with w/o doing conversions in java, where in C the char arrays are usfule w/o conversion. I have always found C and PERL IO better than Java's.
"You will do foolish things, but do them with enthusiasm." - S. G. Colette
I consider using ((x=1)) to supress the warning to be even worse than leaving the warning in.
It's always a long day... 86400 doesn't fit into a short.
I can see no reason for making mandatory garbage collection part of the C++ language. It wouldn't make it one bit more useful; C++ doesn't prevent you from using garbage collection in your programs. If C++ needs a garbage collector(s) then it (or they) should go into the standard library (if anywhere) and not the language itself. Restricting the use of a language will never make it more useful.
Who ordered that?
It's not about "being unfamiliar with C++ syntax". Quite the opposite, someone who writes that way is so familiar with C and C++ syntax that they know how to avoid the common mistakes without batting an eyelash.
The point is, it's only a common mistake for those unfamiliar with the language.
For a pro, it's as common a mistake, as writing if x:=7 in Pascal.
if(7==x) is a way to prevent a beginners mistake, by ruining readability. For programmers above first semester, readability is way more important than avoiding beginners mistakes that they shouldn't be making in the first place.
Yes, some algorithms are worth remembering...
/* do nothing */ } loop and outer while loop. This should not be done. Semaphores might be slower in the specific case, but overall system performance will benefit from using best-practices.
This one is worth remembering as one to avoid -- it's based on the idea of a busy-wait. Look at the while(test) {
There's a reason this algorithm lies in rest in academic journals: it's only useful as a teaching tool.
You've forgotten the exception catcher.
I can logically deduce from your statement that almost all the code you ever see is production code. In which case, I don't think your opinion matters very much.
It's always a long day... 86400 doesn't fit into a short.
There are some subjects that draw fanboy clubs here in
Some examples: Java, AMD, Apple, Ruby.
Try criticizing any of them here, you'll be down-moderated to (-1) pretty quickly. OTOH, praise any of those and you'll get moderated up, no matter how stupid or inconsistent the comment is.
It's been a while since I've used C++, so maybe the part of my memory that held the reason why this is about to be a stupid question was repurposed, but why are you passing it as a const reference instead of just a reference? It still won't make a new copy of the object, right? But then you aren't stuck with only const methods.
C++ is a multi-paradigm programming language, and is still evolving. (Rather, should we call it ID?)
It supports procedural, OO and functional programming, the last still needs improvement. Contract programing is in the works, and will amongst other things alleviate all those nasty template error messages. Fine-grained GC is already in TR1 and should be available from major compilers pretty soon. It is interesting to note that GC is being done in the standard library, unlike C# which does it in the core language. Some would propably claim this means C++ doesn't have "true" GC support, rather than realizing it is just a different approach to the problem.
C++ won't die as long as it keep evolving, even though it is a rather glacial evolution. So to say it doesn't follow new research into computer languages is to ignore the progress that does happen.
- These characters were randomly selected.
An if perhaps wasn't the best example. In a while, though, it can avoid duplicate code.
It's always a long day... 86400 doesn't fit into a short.
This thread goes out to all the HTML turned PHP hackers who whine that Comp Sci is a useless major
Nothing against PHP or HTML of course
So does that make Python a pure OO language since you can inherit from anything?
*sigh* back to work...
I have to say, on average for projects I've had the opportunity to view code for, C++ code is far easier to understand and grasp than the equivalent C code. You can instantly see the structuring of the code and how it correlates. Whereas often the equivalent code in C isn't as clear. Ofcourse this is usually a programmer problem more than anything, since I often see people less structured in their C usage.
In what way is "EOF != (c = getc(stdin)) less readable that "(c = getc(stdin)) != EOF"?
It's always a long day... 86400 doesn't fit into a short.
MOD the parent of this comment up!!!
IMHO this algorithm is not a panacea because :
- It does busy waiting. If one thread holds the 'mutex' for a long time, the other thread will take a lot of CPU for nothing.
If you really need to take the resource as soon as it is available without giving up the proc, then have a look at "spin locks".
- It is not very scalable.
First, you need one version of the algorithm for mono proc one for bi proc, etc. Of course you could put them all in a shared lib and select one at runtime.
Second, the algo seems to be O(N), N being the number of processors. Therefore the algo slows down when the number of proc increases.
- And last: it is unclear to me how you pass turn when there are more than 2 procs involved. Does this algorithm work when there is more than 2 processors ?
The D programming language is shaping up to be a nice alternative.
you fool! Duh!
Are you an idiot! naturally that is where you would implement sleeping or thread suspension! the point is to show the relevant FAST part.
The routines used by linux and even BSD historically (before 1994) were slow, and the current stuff is still not as fast as this, by far.
naturally you would implement your sleep or poll in that section, if more than a microsecond or two elapsed.
the code is a skeleton demonstrating that the massive hit hidden in special opcodes or special os calls can be avoided.
I would have no problem with making a collector as a backup mechanism. Unfortunately Java, C#, etc. provide no other means for managing memory. This assumes that the algorithm is always superior to the engineer. Unfortunately in some cases that's not true and prevents the use of Java, C#, and similar languages.
;-)
-
The other issue is that many of these VM's assuming they're the only thing running on the system. They'll happily consume RAM until available RAM gets low, starving other applications needlessly.
Then there's the issue that they just don't do real well when memory gets paged out. The current crop of mark/sweep generational algorithms don't cut it in many situations. They cause excessive page swapping.
What I want is something that watches my back, but doesn't get in the way. It should allow me to grab the reins and take control when I know more than the GC algorithm does.
I wish I had a moderation point left, I'd vote for troll
Q
You've forgotten the exception catcher.
No, that was actually quite deliberate. When people say they can open and read a file in Perl or C with only one line, they haven't included any error handling, so I think it's only fair to do the same here.
Being bitter is drinking poison and hoping someone else will die
C++ code is far easier to understand and grasp than the equivalent C code. You can instantly see the structuring of the code and how it correlates.
Oh good gods yes! As an example for how all over the place c code can get, try looking into the mplayer source tree. Men have but gazed upon its grim pointer laden facade, and gone instantly mad. Mplayer.c is 4000 lines long!
May the Maths Be with you!
C/C++ doesn't prevent you from coding secure, leak-free programs. All it does is shift the responsibility for security and memory management from the language to the programmer. If you're a sloppy programmer then, yes, you need a better language than C/C++.
Who ordered that?
IWhatever is the hungarian notation for interfaces. CWhatever is for objects that are complete classes.
I aim to misbehave.
Two reasons: // did x get changed?
// legal if foo takes a T const&, but not a T&
a) The called function _cannot_ modify the argument. This becomes important to the code surrounding the function call.
T x(...);
foo(x);
If foo is declared "void foo(T const&)", then you *know* that x has not changed. If instead it's declared as taking a plain reference, you can't know.
b) You can pass const objects or objects with limited lifetimes.
foo(T());
It's always a long day... 86400 doesn't fit into a short.
So, what would it take to satisfy your criteria on being a proper successor to C++, if none of C#, Java, Pike, Python, and many others are unable to qualify?
now we need to go OSS in diesel cars
I wish I had a moderation point left, I'd vote for troll ;-)
Me too.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
It also leaks like a sieve most of the time and has all the security problems seen in C
WRONG! Memory leaks and security problems are not the fault of the language. The programmer is solely to blame. Proper freeing of memory and sane buffer management goes a long way to creating good, secure code. Sure, other languages may take care of this for you, but you can do the same in C/C++ with wrappers if you are too lazy to handle it yourself.
a) You're not impressing anyone by trying to cram your program into a single line of text.
b) If you're so smart you identify the constants and re-order your expression accordingly, then why aren't you smart enough not to avoid the mistake in the first place?
The difference of course being that the C/C++ will still compile, and the Perl actually puts the error handler on the same line:
open my $filehandle, '', 'filename' or die 'omfgwtfbbq!';
"Because Science" is one step from "Because old book". Try "Because of my experiment testing my falsifiable assertion".
You say that as if C++ isn't in use by the vast majority of software houses on the planet, and rather successfully for that matter.
I tried unsuccessfully, verbally, to get a Phd in comp Sci with embedded management experience to believe me it is 100% sound.... argued for 40 minutes. The guy never had a clue.
The guy had a clue. Your algorithm is a busy-wait loop, so your CPUs will be maxed at 100% while waiting, and the thread will be pushed by the scheduler to lower priority, and so on...
a) The technique is commonly used to avoid duplicate code in a loop with priming read. Duplicate code is worse than a slightly more complicated line, as it doubles the work required by a maintenance programmer.
b) One is a habit, the other is a typo. I've been writing in English for far longer than C++, and I still create typos in English every once in a while. The idea that a smart C++ programmer would never accidentally spell a common idiom wrong is absurd.
A smart C++ programmer is one who recognizes common mistakes (*especially* those which might be made by another programmer on his team who isn't as savvy) and adjusts his coding style to make such mistakes less likely, especially when it costs you nothing (it doesn't even increase the character count).
It's always a long day... 86400 doesn't fit into a short.
The only way to read the filechannel is a bytebuffer. Has anyone ever used them? I had to once and it sucked....
I've used them. What did you not like about them?
FileReader (or BufferedInputStream) are still awkward because tehy use byte and string arrays. Those really are hard to work with w/o doing conversions in java, where in C the char arrays are usfule w/o conversion.
Ok, there is also RandomAccessFile which gives you methods for reading all primitives, byte arrays, UTF-8 Strings, whole lines....
Used for instance here to do high performance Linux Cluster Monitoring. Doing a C implementation saved them a whopping one second per day of processor time.
Being bitter is drinking poison and hoping someone else will die
Unix Domain Sockets use shared memory to transfer data between applications. How does this compare to other shared memory methods in performance?
Ok, I get it... it's an attempt to exploit shared memory in C++.
And why is this news? Is it so difficult that nobody has done it? No, that can't be -- the shm stuff can be wrapped. This is so important that it rates a "design pattern"? Not it either -- the one illustrated isn't the best solution.
So, just what is this article? Methinks fluff. Sort of in line with "How to implement co-routines with setjmp/longjmp" thing. Or, "Restructuring data to assist processor cache residency". And "How to remove locks from performance critical MP code".
Except not as interesting or useful.
Ratboy.
Just another "Cubible(sic) Joe" 2 17 3061
It can be tweaked to avlod busy waiting, obviosly. The code is a clear skeleton example. you would sleep, or suspend, or force context switch in the busy wait section after a certain amount of microseconds elapses. Also on can assume that the mutex itself is controlling a single shared VARIABLE or RECORD, and that the entire time waiting is nanoseconds at maximum in best case. THINK!!! This is a special tool, and can be made slower or bloated if needed, but not necessarily nonoptimal even in skeleton design!
secondly :
IT IS SCALABLE for a few tasks. i would not setup more than 20 of them, but many situations only need 3 or less tasks sharing one message bin. Yes of course you need the make X copies of specially crafted code depending on the design.
Remember the point, We are talking over 10 times faster... that is all that counts, and that is still an inarguable fact comapred to the linux example code in the article.
finally : as for how to pass the turn, instead of two opcodes to exit, you would add an increment, and the special code for the final participant would merely set back to 0
FAST FAST FAST!!!! potentially over 500 million transactions per second protecting a tiny data structure on normal machines
You've just gotta love Dekkers
If you mean a pure OO language like Java, in which everything is an object except for primitives stated elsewhere, this is contradictory. Try Python or Ruby. it takes ten classes and wrappers just to read a file ten classes might be too much. Sun went for flexibility and tried to give control to the programmer, exposing the API internals. Java was not designed for quick and dirty applications. But noone prevents you to write your class that eases simple file reading. E.g. package util class MyFileReader { String readFile(File) {... } } In fact you find libraries that do that on the Net. Look at Jakarta commons. Sun's API are a little bit raw in some areas. I think it was by intent. It's a trade of. They expected people to build on top of their fundations. They're not Microsoft. I tell you what though, C++ is still around after all this time. So it COBOL. Languages don't go away. the god awful sytax Stroustrup left them with C++ was *designed* to be like that. It had some requirements with regard to syntax being close to C. It requires discipline to use. But it's not that bad a language. Otherwise it wouldn't have been used as it has. There is still no successor to C++. successor for what goal? A language is a tool and not a universal solution. Java is better for some tasks, so is Ruby, Python, C#.... C++ has its uses, but today, although I like it, I find myself much more productive using other languages. Go and write a cross platform internationalized C++ web application with a thick client to communicate with. I wouldn't even know where to start.
Sneak teach kids Algebra using a game
The difference of course being that the C/C++ will still compile, and the Perl actually puts the error handler on the same line:
I wouldn't call instantly ending a program with an error message "handling" a problem. If you have no demands on program reliability, you can always throw a RuntimeException("No such file: + fileName") in Java too.
Being bitter is drinking poison and hoping someone else will die
I've seen this before, but why is C/C++ marked as a high-level language (as in the summary)? C/C++ are LOW-level languages - closer to the hardware, while languages like Visual Basic are HIGH-level languages since they abstract hardware-related tasks like memory management away.
-- Proof by analogy is fraud.
That breaks down sometimes, sure, but that's when your "backup mechanism" would come into place
Either way, you should always have options. At least I can bolt on GC (bhoem) to C++, I can't choose anything but GC in Java or C#. From what I've heard GC will probably be offered in the next standard of C++.
Most of the leaks people talk about are from old style C++. With smart pointer classes and such I rarely if ever have to explicity remember to add a "delete". And I rarely have memory leaks. Where that breaks down is in cyclic references. And I only occasionaly encounter situations where I have such cyclic reference and where ownership isn't clear cut. But for those cases, I really wished for a GC mechanism in the language.
But I think it boils down to giving the engineer a selection of tools not limiting his selection. --
Q
I just realized, I'm a C# dev, so that may not actually be how it is in C++. Sorry for the confusion.
I aim to misbehave.
That everything is an object in Java except for the primitive types are such a cop out by Sun.
Is this really such a problem?
The standard wrapper classes(Integer, Double, etc.) have been around since 1.0 and are part of java.lang so they don't even have to be explicitly included in the code.
I've never been confused as to when I needed an object over the effeciency of a primitive data type.
And as of 1.5, the collections classes automatically box and unbox primitives into their corresponding wrappers.
"If they have both, tell them we use Linux. And if they have that, tell them the computers are down." -Dave Chapelle
"Easy programming languages"
Excuse me? C may be many things , but easy isn't one of them.
Ask any beginner. And as for the "security problems" in C , as
you well know , C was designed as a replacement for assembler.
It wouldn't have been much use if it didn't give you
complete flexibility wrt memory access, even if that means
breaking some of the rules that hand-held high level programmers
use as a crutch because they're unable to code to the metal.
"are uninterested in quality and very interested in meeting deadlines"
If you have a mortgage and a family and your boss threatens you
with the sack if you keep missing deadlines very few if any
programmers will take the "moral" stand and get fired. And frankly,
anyone who puts coding principles above their family is scum IMO.
"In Smalltalk, everything is an object even the primitive classes!"
And thats why it was so goddamn slow on old 16 bit machines
and no one used it.
Actually I tend to find the opposite. With C everything has to be explicit. ie you want a function called, you have to call it at
that point in the code. WIth C++ you can use opertor overloading,
polymorphism, hidden convertions , template specialisation and lots of other stuff which makes the actual code more implicit than C and hides whats actually going on away more. Sure , if you spend some time looking at the code you'll figure it out , but C++ doesn't IMO lend itself to skim reading as much as C does.
"Contract programing is in the works,"
Great , more unwanted flavour-of-the-month-in-the-academic-ivory-
towers cruft in an already bloated language. How many more ways can
people think up to make a CPU run instructions over data?
A lot of shared memory synchronization and/or caching problems can be solved on Linux through the effective use of a few simple things:
1) shm_open (if seperately-started processes which need to coordinate in shared memory), or mmap(MAP_SHARED|MAP_ANONYMOUS) for a process which will fork children which need to communicate/share between themselves and the parent.
2) Use 's "atomic_t" integer type within that shared memory array (atomic_t* my_shm_array = mmap(....)). The atomic_t type has several functions defined in that header for atomic read, write, increment, etc for the linux hardware platform at hand. On most sane (cache-coherent) SMP architectures, reading and writing are already atomic operations, so this basically devolves to just setting and getting integers like normal (with a little bit of syntactic sugar (struct { volatile int val }) to make sure the C compiler doesn't optimize things away that it shouldn't. And you can implement a whole lot of sane algorithms using nothing but shared memory integer reads and writes with no locking or special atomic increment ops.
3) If you need more advanced or complex locking on the shared memory for synchronization, use Linux's "futex"'s. They're in the man pages, and they're really fast.
11*43+456^2
Yes, but in every instance I have seen C++ programmers end up implementing reference counting (by hand) in order to make these problems tractable. Unfortunately reference counting is a horribly inefficient solution compared to a decent garbage collector. Often C++ programmers don't understand why reference counting is a bad idea, assuming that just because its large cost is spread over many operations it must be "obviously" better than those "stop-the-world" (bad) garbage collectors you find in Emacs and Java 1.0.
Rich.
libguestfs - tools for accessing and modifying virtual machine disk images
nobody forces you to use these new bytebuffers, they are mostly intended for async i/o, which most applications certainly dont need, their misuse makes things a lot worse usually :D
last time i checked, new FileInputStream("foo.txt") returned a sane 1 class wrapping around InputStream, which is actually as close to the ideal OOP model as it gets.
java's big advantage over old generation programming languages is that char != byte, which makes all kind of utf8 and utf16 handling transparent and very comfortable. for unexperienced new players, this ofcourse gives a lot of painful lessons too. the other big advantage is that all java libraries (unless written by serious "einsteins") can be mixed with eachother without much trouble, whereas very many languages have brilliant api's for some things that don't work with some other brilliant libraries at all (ithreads and lwp|tcltk for perl as an example).
c++'s biggest power imho is to directly include pure C code without any special hacks, this allows you to use the very core libraries of your operating system and gives it speed and comfort using the standard stuff, this is something that most languages miss big time.
comparing the stuff is pointless as stated many many times before by many many people besides me. use the right tool for the right job. c++ is the right tool for many things right now, use it where you have to use it (unless you have something that really is better, which is not mostly the case for low level stuff)
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
The article is about shared-mem and synchronization accross process boundary! In Java that would mean: object that are shared between VMs; methods are are serialized across VM boundary.
Bogus
Yeah, this algorithm is fast. Too bad that it does not work. This kind of design is a common mistake by people who do not understand the intricacies of multithreaded programming. In short, it fails miserably when the CPUs are allowed to reorder loads and stores, a.k.a. pretty much any modern CPU. You need a memory barrier between setting and testing of a shared variable.
Google for Dekker's algorithm and memory barrier - you will find better explanations of the problem there than I could type up in my limited time here right now.
WRONG!
The Phd had no argument based on efficiency... he claimed it was physically impossible to avoid special hardware support (opcodes, mem control, etc).
By the way it is 100% efficient if two cpus are sharing a single cacheline of memory as a small communications status record.
imagine that reads or writes are bracketed around the cacheline with a call to the mutex.
as soon as the byte or bytes are read or written, the mutex is dropped.
idiots like you would take that pristine 100% optimal example of 500 million transactions per second and slow it down over 100 times slower probably!
Do you ever think about what you are claiming! I am sorry i tried to teach anyone anything here.... its like talkign to retards. I have a respected Com Sci degree and it was not clearly discussed in the older days when i got my worth-crap diploma. instead people rely on HARDWARE based semaphores in machines. THERE IS NO NEED FOR THEM and that is the point.
Well... i would rather recommend a good Haskell compiler as it's the successor of CML and a bit cleaner too. ;)
Or use Ocaml if you like it lightning fast. (meaning: nearly beating raw C) Even in bytecode! (Beating java by far!)
But it's not as clean as Haskell as it allows *shudder* side effects...
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Like Java, right?
Getting back to the original premise of the story, can you even do OS-level shared memory (SysV or POSIX) with Java? OS-level semaphores? Any meaningful kind of IPC? OS-level anything? I mean without godawful JNI nonsense.
In the course of every project, it will become necessary to shoot the scientists and begin production.
Of course, there is still some debate about what "Object oriented" means, and what it means to be "pure" OO. And by debate I mostly mean a combination of Usenet flaming and the academic equivilent of trash-talking. Suffice it to say that there is not a universally accepted definition of "object oriented", much less "pure object orientation".
It has something to do with the direction in which you read the code, from the left to the right. In the former example, you'll have to push "EOF !=" on the mental stack before parsing the meaning of "(c = getc(stdin))".
I like my manga right to left, my code left to right.
- These characters were randomly selected.
In the same way that "elbadear" is less readable than "readable".
Fine-grained GC is already in TR1 and should be available from major compilers pretty soon. It is interesting to note that GC is being done in the standard library, unlike C# which does it in the core language. Some would propably claim this means C++ doesn't have "true" GC support, rather than realizing it is just a different approach to the problem.
TR1 does NOT provide "Fine-grained GC". It provides std::tr1:shared_ptr, which is capable of solving some of the automatic memory management[1] requirements of SOME programs and completely fails (as in "unbound memory consumption") in others. While indeed being a different approach to memory management, it is nonetheless not a "true" solution by virtue of being non-transparent (i.e. not fully "automatic"), incomplet and inkorrect.
The above, of course, assumes the said smart pointer is impemented with reference counting, although the standard does not mandate particular implementation. However, any other implementation, which is both transparent, complete and correct would necessitate a C++ runtime, which would make the smart pointer, well, pointless in the first place.
[1] the proper name of the so called "garbage collection"
The mutex doesn't seem to be shared between processes. This would make the code incorrect. Can anyone confirm this ?
The neat thing about "die" in Perl is that it instantly converts into an exception just by wrapping the function call inside an "eval { }"
Balanced like tr1::shared_ptr and friends in TR1? The lack of standardized GC support in C++ is no longer a valid argument. Now all that is needed is for them to be implemented in the major compilers.
Though it still doesn't solve the problem of bad coders.
- These characters were randomly selected.
(Ignoring the typo)
More like still perfectly understandable this sentence is.
It's always a long day... 86400 doesn't fit into a short.
C and C++ already have precedent for reading things backwards: /* foo is an immutable pointer to an immutable integer */
int const *const foo;
It's always a long day... 86400 doesn't fit into a short.
The code shown is using pthread mutex for sync-ing. The mutex works only for synchronization of threads, not processes so the code is useless (even dangerous) for inter process communication (IPC). In the case of threads another question is just screaming for an answer:
Why would someone use a shared memory block for threads which are all running in the same memory space anyway?
We come to the conclusion that the code is quite useless for inter-thread communication too. All in all - useless.
The PhD is STILL right.
That code makes a huge fundimental assumption, that write order is preserved. In other words, if you do:
Write to location 3 on processor 1 (take the lock)
Read from location 30 on processor 1 (do stuff with the lock held)
Read from location 3 on processor 2 (check the lock)
that the reads and writes will appear in order. On ALL modern processors, this assumption is not true, it's possible for the write to location 3 to occur AFTER the read from location 3 on processor 2. It works great on single processor machines, but fails on MP machines.
In order to make the code work, you need to put a memoy write barrier after the write to location 3, this will force the write to be flushed from the cache.
I'd say it is entirely a programmer problem. C++ programmers who write C programs (for whatever reason) tend to organize things just as they would a C++ program.
[Set Cain on fire and steal his lute.]
This is of course a textbook algorithm. Every textbook will also tell you that it has a fatal flaw (except from the busy waiting, which the textbook we were using (Ben-Ari) wasn't even interested in): if a process that holds the turn crashes or terminates, the whole system deadlocks. That makes the whole thing, unfortunately, rather useless.
technically, you don't "know" it's not changed. the function could be using const_cast<> and changing it that way. but then of course that function's violating it's contract :)
--vat
It would still result in massive CPU usage, compounded with potentially lots of MOESI traffic on the caches. These are some of the reasons why it isn't used anymore. If it were the end-all, be-all as you claim then why wouldn't this be used everywhere? I mean, it's not like the algorithm hasn't been around since 1965 (as you also stated).
Basically, the reason is this: Polling, especially in a single CPU environment, is a BadThing(tm) if you want your machine to handle load well. If you have no load and have nothing else useful for your CPUs to be doing, then polling is about as good as anything else. Considering that all modern OSs are pre-emptive and are doing lots of things during any given second, few would meet that criteria.
Compounded by the fact that many "by hand" implementations of reference counting is defective. I've seen many broken hand-tooled reference counting schemes.
java.nio.* and java.util.concurrent.* provide relatively high level API that is implemented with the most efficient OS calls possible (actually it depends on the quality of the implementation. . .).
It may not be as general as straight Sys V IPC or what have you, but it will probably cover the majority of cases.
It's still good practice. One day you might working with an older compiler for some reason (perhaps on a maintenance project) that doesn't warn. Perhaps you'll be working with another language that isn't so helpful: for instance I've been working on some ECMA Script applications recently and my habits like this from the old days of C++ help me deliver more reliable code.
That is what I said, yes.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Not really, no.
Getting back to the original premise of the story, can you even do OS-level shared memory (SysV or POSIX) with Java?
I dunno. Never tried. I would imagine not, given the sandboxing that goes on.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
You don't get it about out-of-order writes, do you? Simple scenario, according to your algorithm:
/* CPU AA clears its BUSY flag at this point in time, so, the while (flags[AA] == BUSY) terminates immediately */
/* from AA */ /* from BB */ /* BB uses the resource */ /* writeback from AA is too late */
CPU AA:
resource = produce_something();
turn = BB;
flags[AA] = FREE;
CPU BB:
flags[BB] = BUSY;
consume(resource);
The problem is that AA is free to reorder its writes. So, the actual order could be:
flags[AA] = FREE;
flags[BB] = BUSY;
consume(resource);
resource = result of produce_something() call
Oops. BB accesses the resource before AA writes back the current state. Cache coherency does not solve this problem - the problem is that the write to the resource is still pending. That is what the memory barrier is there for.
Argue with facts, don't hide behind oh-so-impressive credentials.
But the point is really that the compiler "knows" it is not changed, which lets it do various optimizations it could not otherwise. Which might well cause problems if you use const_cast<>
Personally I think actions have no business whatsoever inside the condition clause of an "if", "while", etc. "x = foo()" can easily go on another line. And if someone is sick enough to really want a side-effect inside of a boolean clause, they should use parens to make the order of operations easy to read.
As for the more general issue of "backwards comparisons"... The big thing I guess is that it helps people remember not to type "if (x = 3)" or whatever... not that that'll help them if both values being compared are variables.
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
C/C++ doesn't prevent you from coding secure, leak-free programs.
That is exactly what I said.
Who ordered that?
I'd say anybody doing either has poorly-written code. Stop trying to do so much on one line. With our massive displays these days code doesn't become less readable when spreading things out over more line because we can see so many lines anyway. Spacing the code out more vertically makes it easier to read and less error-prone too.
...
c = getc(stdin);
if (EOF != c)
{
Does that count as a replacement?
Compared to most languages, C is very easy to pick up the basics of. That's why C-like languages rule the programming world. There are some tricky parts but the basic structure of a C program is something even beginners grasp very quickly, and I've tutored quite a few.
If you have a mortgage and a family and your boss threatens you with the sack if you keep missing deadlines very few if any programmers will take the "moral" stand and get fired.
Which is why so much code stinks. Just because there is a good reason for it stinking doesn't mean it suddenly becomes good code or stops crashing. There's no "Blue screen of morally acceptable quality compromise" that pops up and then allows the program to continue on as if nothing had happened.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
"How many people know about this? Nobody! I never read about it anywhere. I invented it myself years ago, .."
Turn to page 55 of your OS design and implementation by Tanenbaum. See where he says, "For a discussion of Dekker's algorithm, see Dijkstra (1965)."? How do you get through a proper comp sci honours degree to the point where you can take a masters and then a PhD without reading Dijkstra?
How about you crack open that copy of Operating Systems (4th ed) by William Stallings, which has a discussion of concurrency and Dekker's on pages 208-213? How can you get past a 2nd/3rd-year introductory operating systems class without having gone over this topic?
You are a troll. A troll preying on the fact that most of the moderators here have no idea about computer science, and have not taken a wiff of a real operatings systems class.
For the record, Peterson's algorithm (published in 1981) is a much simpler solution to your problem. It's on page 56 of the Tanenbaum book, and also discussed in Stallings on page 213. There's a new 5th edition of the Stallings book, but the index will take you to the correct chapter/page in short order.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
And yes, it's still single entry/single exit - it's just that the exit is syntactically in the middle of the loop body.
The Tao of math: The numbers you can count are not the real numbers.
I would dispute the second part: has code quality improved in these houses, or anywhere in the last 15 years for that matter? Has the number of late, canceled, or over-budget projects decreased?
I simply don't believe that the currently popular languages have anything substantial to offer when it comes to solving the big problems of computing. C++ is a hack, but it is a very popular hack which brought the concepts of OOP to a lot of people. Just enough of those concepts, in fact, to stop most of them asking for more.
Not having a GC, retaining the idea of keywords and primatives, the dire template system. These are all huge flaws in the OO model of C++. Some have been patched over the years and some are being patched as we speak, but I have little faith left in the language as anything other than a useful deadend, like COBOL was in its final years.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
WIth C++ you can use opertor overloading, polymorphism, hidden convertions , template specialisation and lots of other stuff which makes the actual code more implicit than C and hides whats actually going on away more.
C++ code tends to more clearly express the programmer's intent. C code tends to more clearly express the implementation details. When reading C, you start by looking at what the code does, then work upward to figure out what the programmer intended to accomplish. When reading C++, you start by looking at what the programmer wanted you to see, then dig down to find out exactly how it was done.
That's all a gross generalization, of course. C can be written so that it's very clear, C++ can be written so that it exposes the details, and both can be horribly obfuscated.
Assuming both were written by good programmers, I'd rather read C++ than C. It takes less effort to get the gist of what's going on, and I can always dig into the details if I need to.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
"There are some tricky parts but the basic structure of a C program is something even beginners grasp very quickly, and I've tutored quite a few."
,unions, stdio buffering, pre processor
Structure is hardly the same as syntax , and C structure is
simply procedural anyway. Explaining pointers , dereferrencing,
stacks, heaps, bitfields
tricks and all the other stuff you need to become a *good* C
programmer to beginners is not easy. Any idiot can do printf("hello world\n");, but take that idiot and give him the linux
kernel code to look at and then tell him C is easy.
Actually, foo is an immutable pointer to a possibly immutable integer (it can also point to a mutable integer).
Now, you hopefully don't think C++ declaration syntax (which is this way due to C backwards compatibility) is something you should imitate. Indeed, Bjarne Stroustrup himself said: "I consider the C declarator syntax an experiment that failed." (in the answer to question 3, paragraph 4)
The Tao of math: The numbers you can count are not the real numbers.
There is another assumption that may not hold (but usually does).
The code assumes that a writes are atomic. This will almost always hold for 8 processes and usually form 32, but if the flags array is larger than a word, atomic writes go out the window.
However, given that these people are IBM engineers, I'll give them the benefit of the doubt -- can somebody explain what I'm missing here?
I think it's perfectly fine to subscribe to the OP's take on this: a language is purely object oriented if all instances of all types are objects, except for the ones that aren't.
Are you adequate?
Experience demonstrates that, by and large, even very good programmers commit a sizeable number of these errors. Not to mention that ensuring proper security and memory management takes time; and time is money.
Are you adequate?
Yeah, I just *hate* it when they define things in .hh files and put the implementation in .cc files.
Those are the wrong file extensions, you rat bastards!
Show me on the doll where his noodly appendage touched you.
Even with thread suspension, you need to wake up every so often to check the status of the flags. This leads to one of two outcomes.
1)YOu use a long sleep timeout. This means your responsiveness is lower than using an OS semaphore, because you won't be woken immediately upon thread B finishing.
2)You use a short sleep timeout. This means you will wake up and check the flag repeatedly. That measn incurring a contaxt switch into the program for every poll, which is far more costly than the switch to kernel mode.
I still have more fans than freaks. WTF is wrong with you people?
C++'s biggest power by far is templates. For those of us writing graphics software, there is no better way to write one bit of code that operates on various pixel depths (8 bit channels, 16 bit channels, half float channels, full float channels), and let the compiler deal with the instantiations.
Not many people mention this. When speed is paramount, and you need portable code, there is nothing better than C++.
Any idiot can do printf("hello world\n");,
The same idiot can easily grasp for loops, ++, --, subroutines and parameter passing, and a host of other syntax which allow the writing of useful programs in a very crude way, but they will work. And that's the problem. Once they get to this point the beginners think they are programmers and off they go to ply their trade. When they see C++ they think "Oh, I recognise this. There's some extra stuff about classes but that's just a way of organising your subroutines." and away they go. The end result is the sort of buggy code I see all the time, failed projects, cost overruns and unintelligable source.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
You're hoping that the compiler decides to use a bitfield for booleans then. This does not have to be the case- a compiler is free to implement them as whatever they wish. I would expect chars to be a common choice. You'd need to rewrite the code as bitfields to ensure that.
I still have more fans than freaks. WTF is wrong with you people?
why are you passing it as a const reference instead of just a reference?
Two reasons: Readability and const-correctness.
When writing C++ it's a good idea to avoid passing parameters by non-const reference because doing so creates too much work for the next programmer who has to read the code. Since references don't exist in C, and many C++ programmers also write C, there's a natural tendency to assume that functions do not modify their parameters. This means there's a good chance that the next programmer who comes along will assume that your functions don't modify their parameters. If that assumption is invalid, he may break something. Even if the next programmer realizes that your function may modify its parameters, it's a problem because then he has to look at every function to find out if it does or not. If you're going to modify a parameter, pass a pointer, and try to take the address in the function call so that it's very visible.
It's quite clear in the above that someMethod is probably going to modify aParam.
So it's good style to avoid passing parameters by non-const reference. Passing by const reference is okay, because it doesn't change the semantics (excepting possible side effects by ctors/dtors or usages of const_cast<> by the function, but those are generally very bad style). Since it's semantically equivalent to passing by value, but more efficient, it's a good idea.
Const-correctness is a very valuable tool in a C++ programmer's arsenal. The idea is that all objects, parameters and methods should be declared as const except where they actually need to change/be changed. This really helps to expose invalid assumptions about when things change and often enables the compiler to catch some programmer logic errors. It can also be a huge amount of work to make a program const-correct, and efforts to do so may run afoul of const-incorrect library APIs. IMO, const-correctness is sufficiently valuable to be worth doing, but probably not valuable enough to try retrofitting into an existing codebase, except perhaps as an exercise to build an understanding of the structure of the code (because you're gonna see almost all of it!).
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
In addition to the problems of write ordering and busy looping, I have one more- your solution works only if you know how many threads will be accessing the resource beforehand. You have to choose an array size for the flags, and hope that you guessed a high enough number. That may be ok for some subset of problems, but not for a general solution.
I still have more fans than freaks. WTF is wrong with you people?
What is your point, Java would be just as slow if not slower when implemented on such hardware with said limitations.
There were probably other reasons as well, the whole image vs. source thing. Smalltalk was just too different.
0x1234... Amazing that's the same code I use on my luggage
C++ is more than just an OO language. It provides direct support for the procedural paradigm too.
STL, for example, is not an OO library. Yet it has proved to be immensly useful.
One place where the garbage collected languages fall down is in the management of resources. The handling of limited resources such as files or sockets must be explicitly released by the programmer. This demonstrates that you simply cannot ignore the lifetime of objects with a garbage collector. And I also assert here that memory is a limited resource too.
That silly singleton thing in the example is a demonstration of the disregard for the lifetime of that particular object. Does it really need to live for the lifetime of the application? Does it need to be cleanly released?
I think C++'s memory management model is sufficient. One can hardly say that about garbage collected languages.
I don't see a difference- the authors intent is the implementation details. Then again, that may go a long way to explain why C and assembly are my favorite languages :)
I do agree though- a good programmer will write good code in any language, a bad one will write bad code in any language. I prefer to just ensure I hire/work with good coders, and use a language that doesn't get in the way. (The other reason I like C- the compiler never makes a choice or a guess- what you write is what you get).
I still have more fans than freaks. WTF is wrong with you people?
Interestingly, you omitted the sentence that I had following it- "Think of all the hacks that result just from that." Wrapping and autoboxing are hacks. Wrapping primitive types result in objects much bigger than they have to be- Lisp and Smalltalk people figured out type-pointers a long time ago. Autoboxing is an ugly fix, a performance hit, and its existence is a wart. Why don't the reflexive libraries work with primitive types? Primitive types were a cop out by Sun; they could have spend time and got it right but that would probably mean addition JVM complexity and time.
Precisely, I think he was saying that you cannot recover from segfaults when using threads, and that this is yet one more reason why threads are a bad idea in Unix (for user apps). In any case, it is common wisdom that SysV IPC methods and threads do not mix well at all.
Well, darn, I thought UNION was the best way to share memory...guess it's time to upgrade my skill set
never bring a twinkie to a food fight.
On top of those mechanisms, even slower interprocess communication systems are typically implemented, such as OpenRPC and CORBA. (For even more inefficiency, there's XPC. In Perl. But I digress.)
Because of this history, there's a perception that interprocess communication has to be slow. It doesn't.
What you really want looks more like what QNX has - fast interprocess messaging that interacts properly with the scheduler. QNX has to have interprocess communication done right, because it does everything through it, including all I/O. This works out quite well. You take a performance hit (maybe 20% for this), but you get much of that back because the higher levels become more efficient when built on good IPC.
The QNX messaging primitives are available for Linux, although the implementation isn't good enough for inclusion in the standard kernel. That work should be redone for the current kernel.
IPC/scheduler interaction really matters. If you get it wrong, each interprocess transaction results in an extra pass through the scheduler, or worse, both the sending process and the receiving process lose their turn at the CPU. This is easy to test. Start up two processes that communicate using your IPC mechanism. Measure the performance. Then start up a compute-bound process and measure again. If the IPC rate drops by much more than a factor of 2, something is wrong. Don't be surprised if it drops by two orders of magnitude. That's an indication that IPC/scheduler interaction was botched.
Sun addressed this in the mid-1990s with their "Doors" interface in Solaris, which had roughly the right primitives. But that idea never caught on.
The article here implements a message-passing system via shared memory, which is not exactly a new idea, even for UNIX. I think it first appeared in MERT, in the 1970s. It's an attempt to solve at the user level something that the OS should be doing for you.
Shared memory is a hack. It's hard to make it work right. With it, one process can crash other processes in hard-to-debug ways. Sometimes you need it because you're moving vast amounts of data, (by which I mean more than just a video stream) but that's rarely the case.
Hi! /. crowd would help me...
/var/www/html/sharedmem.php on line 2
// These are fine
/*$shm_size = shmop_size($shm_id); // Now lets read the string back
I have a prob with shared memory in PHP and C++ I thought the
I have a server written in C++ and my webpages are in PHP. The PHP has to communicate with the server using shared memory. This was working fine on the server running FC-1 with php-4.3.8. We recently migrated to CentOS 4.1 (Equivalent to RHEL 4.1) running php-4.3.9. The error it displays is as follows:
shmop_open(): unable to attach or create shared memory segment in
The server opens the shm in 666 (originally was 644) even then it was not working. I can see the shared mem open using 'ipcs' command.
The source code of PHP is as follows:
";
# print $shm_key;
$shm_id = shmop_open($shm_key, "a",0,0) or die("FATAL ERROR:: Unable to Access Shared Memory");
DEBUG:: print ("Shared Memory Block Size: " . $shm_size."\n");
*/
$data = shmop_read($shm_id, 0, $shm_size);
if (!$data) {
echo "FATAL ERROR:: Couldn't read from shared memory\n";
exit;
}
?>
Both the configs say that 'shmop' is enabled.
Can some one help me with this, I am in desperate need of this, if this fails I might have to search for an alternative and the project has to go live in a week or so. I am in desperate need of help, can any one help pls?
Regards,
Yaswanth
Yes, recent versions of Python are purely OO.
You can tell a pure OO language from an impure OO language because you have to resort to boxing (or if you're lucky, autoboxing). You're stuck using classes like java.lang.Integer.
Cyric Zndovzny at your service.
I cant believe i am even bothering to rebutt you again... did you READ wht you wrote above carefully?
Do you understand cacheline coherency? It does not matter the ORDER of the bytes written out.... first of all only ONE byte in the cacheline is intended to be used or defined. Each flag ought ot be in its own cacheline (ignore the C syntax for the declaration and assume the "boolean' is padded into a structure large enough to guarantee one flag per cacheline..
secondly... if a process requests a cacheline and it is coherent and not opaque in L1 L2 or possibly L3 caches... then the REAL DATA is resolved and fetched.... not stale corrupt old data.
thirdly the algorithm itself can be immune to out of order writes on the bus, even without this because it uses TWO flags and both have to be logical before it can advance... since the other cpu is coherent to its own access to the "turn" variable, it knows if it is its own turn or not.
the order the bytes touch physical ram are irrelevant to Dekkers algorithm... all that matters is that the access of the flags are caceh coherent amoung processors or processes.
we are talking about coherent cache. if coherency cannot be guaranteed, then merely allocating the page uncachable or setting the cacheline uncacheable can be done on all normal hardware.
as for the order the bytes hit memory.... its irrelevant and does not hurt a wisely implemented Dekkers algorithm.
the reason my drivers are closed source is because I am tired of teaching programmers in india how to write drivers and firmware... just as I hate showing people how to make things 10 times faster.
This entire excercise has reminded me not only how stupid the PhD in comp Sci was to refute the validity of Dekkers.... but now it seems the same non critical thinking buffoon infest slashdot.
This is highly application depedent. Stack object is allocated at compile time. If there are things whose allocation size can't be determined at compile time, the only alternative is through new/delete.
Together, we are strong; Apart, we are stronger.
Using feof(3) to check for the end of stdin is better still, unless you can be sure the EOF character isn't going to collide with anything in the input stream.
Ita erat quando hic adveni.
Interestingly, you omitted the sentence that I had following it- "Think of all the hacks that result just from that."
Not that interesting. I was just assuming you meant hacks arrising in the use of the language. Not hacks Sun had to use to put it together.
Wrapping and autoboxing are hacks.
Possibly. But they are clearly documented and were well recieved when 1.5 was released.
Why don't the reflexive libraries work with primitive types?
Introspection on primitive members of a class gives you the corresponding wrapper class type. Whether or not that is a working implementation is debateable I guess.
Primitive types were a cop out by Sun; they could have spend time and got it right but that would probably mean addition JVM complexity and time.
They've had millions of dollars and over ten years to change things. I doubt the decisions made were simply due to time constraints or additional jvm complexity.
If anything its likely that the JCP doesn't see this as a big enough issue to steer things away from its present course.
"If they have both, tell them we use Linux. And if they have that, tell them the computers are down." -Dave Chapelle
I never saw the randomaccessfile class, how did I miss it, It's pretty much what I was looking for:-p
The mappedmemory just seemed combersome to work with, not that it was hard or bad, just it felt awkward.
Just as a side note. Apparently Java is catching up with C. The garbage collecting is done very well and doesn't slow it down like it use to. Maybe it's because I'm an old C guy, but there is just something about Java I don't perticulary like. It's a great lang and all teh libs are nice, but, idk. I like my pointers and all the hardships (and bonuses) that come with them...
"You will do foolish things, but do them with enthusiasm." - S. G. Colette
Why?
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
It being C++, we shouldn't really be using either. ;)
/*| std::ios::binary*/);
// Read from input...
std::ifstream input("", std::ios_base::in
if (!input)
{
}
while (input.good())
{
The reason to use feof() is that EOF can be returned for error conditions *other* than end-of-file. However, EOF cannot occur "naturally" in the input stream. That's why getc() returns an int and not a character.
You are confused. "Garbage collection," as usually defined, is orthogonal to the handling of non-memory resources.
Languages that support automatic memory management generally behave identically to C/C++ with respect to file descriptors, so they can't be any worse than the equivalent C/C++ code in that regard.
A C/C++ program that free()s a memory block (and properly avoids referencing it afterward) which holds a data structure with a file descriptor that is no longer needed, but which does not close the file descriptor, has lost that resource just as surely as a similar program in a garbage-collected language would.
No, in C++ it is perfectly legal to do this:
char foo[strlen(bar) + 1];
to create a stack-allocated object that will be reclaimed when the stack is dismantled. However you can't always control stack size, and it is profoundly unwise to allocate most of your application's storage on the stack, in case you run out, or in case the VM system doesn't page stack memory as it does heap memory.
-- professional C++ developer
Nothing solves the problem of bad coders.
Except when you use exceptions. Then your object's destructor can't get called and anything that it allocated dynamically doesn't get freed.
The problem with Java is that it uses garbage collection, which handles the 90% of the problem that is memory, but it takes away destructors, which hurts when you have to deal with the 10% of the problem that is non-memory resources (file handles are a good example, but there are others).
Way to reply to a troll with another troll.
I'll give you a hint, guys: you're both wrong.
That's what the STL is for. Need to allocate a bunch of SomeObjects? Then make a vector. Sure, this is really just hiding the new/delete, but it does more than that. It encapsulates the allocation behind an object. This means that you only have to ensure correct allocation/deallocation in one place (and this is done by your compiler maker, who hopefully knows a thing or two about good code). It also makes the code exception safe (despite what the AC says below). If an exception is thrown after the allocation, the vector's destructor will deallocate all the memory in its destructor.
Sure, there will still be reasons for new/delete (for example, objects shared among other objects), but it doesn't have to be on every object creation. If used effectively, memory practically manages itself in C++.
"Save the whales, feed the hungry, free the mallocs" -- author unknown
That's completely wrong. If an exception is thrown, any objects on the stack are correctly deallocated, including calling each object's desctructor. This is one of the big benefits of allocating on the stack.
"Save the whales, feed the hungry, free the mallocs" -- author unknown
That works only in C99 but not C++.
Slashdot would be a less noisy and inaccurate place if engineers like you did not bother trying to help out on slashdot any more.
HTHHAND.
Dude, you DO realize they teach this to first year CS students at Drexel, right?
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
Meanwhile, people who have actually learned to deal with C reasonably well have invested so much time in learning this "easy" language that they are terrified of the learning curves of others, particularly when the syntax is visually different.
I consider this whole discussion to be about C and the common subset of C and C++. So pointing out that it's in that it's from that subset is not only immaterial, it strengthens my point.
It's always a long day... 86400 doesn't fit into a short.
EOF is *defined* to not be a _possible value_ of /any/ character in an input stream. Care to rethink that point?
It's always a long day... 86400 doesn't fit into a short.
It's ugly, and it's a hack. Specifically, adding top-level parentheses never changes the meaning of an expression, and programmers shouldn't pretend it does. Though frankly, I should expect no less of people who think that "compiling without errors" is a good thing. It's people who think that way that cheapen casts, eg
int foo = dbl1 * dbl2;
If the conversion is what you want, that doesn't need a cast, thankyouverymuch, no matter what the compiler warns. Adding a cast doesn't "make the code clearer", it "makes it clear the coder doesn't know C".
Besides, a compiler is free to issue a warning that there are starving children in China. Warnings aren't part of C and shouldn't *govern* the way you write code. (Guide maybe, govern no.)
It's always a long day... 86400 doesn't fit into a short.
That often breaks shop coding guidelines which come down from on high. I've considered writing that way myself, and I do so on occasion (when the while condition would be really complicated), but in general I think using the idiomatic style really is the best. Plus, it doesn't step on the toes of structured programming pedants.
:-P
Oh, also, "while(1)" flags a warning in GCC, so it *must* be evil.
It's always a long day... 86400 doesn't fit into a short.
The fact that C declaration syntax is bad isn't in any way affected by the fact that it's also used in C++. Please read the quoted sentence again. Note that the word "C++" doesn't actually appear in it.
My side remark was just preventive against the wrong argument that since C++ has not changed the C declaration syntax (except for adding syntax for C++-only features) would somehow imply that there's something good about the C declaration syntax.
The Tao of math: The numbers you can count are not the real numbers.
well a stop the world garbage collector is extremely bad for percieved performance even if its aggregate cpu time usage is smaller than that of reference counting. I think that may be one of the things that got early java a bad name.
I DON'T CARE if code is slightly and CONSISTANTLY slower than the best achiveable, that can be optimised if it becomes a problem. I DO CARE about unpredicatable long hangs.
btw whats the GC like in opensource java atm? from things i've read i get the impression its nowhere near as advanced as what sun is using nowadays.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
It's also possible to schedule garbage collection in some circumstances - for example by carefully sizing the heap and scheduling garbage collection so it occurs when the machine is idle, these guys have apparently implemented a real time cutting machine on top of a single-threaded garbage collector. I wrote an OpenGL game in OCaml where I scheduled garbage collection to occur between frames, and the game doesn't hang (which would be really annoying in a game as you can probably imagine).
The real problem though is that after the 10th time you do it, implementing reference counting is really uninteresting. I'd rather be getting on with delivering applications.
No idea about Java. Last time I used it which was only 3 years ago, it was still slow, despite what everyone says, and anyway it's a horribly restricted language for real world use.
Rich.
libguestfs - tools for accessing and modifying virtual machine disk images
I didn't say it was good or bad. I said that it is precedent for stating things "backwards" (to avoid ambiguity, I mean "right-to-left") in C and C++. In particular, I was responding to someone who asserted that code /should/ be read left-to-right; they were demonstrably wrong.
It's always a long day... 86400 doesn't fit into a short.
He didn't assert that it should be read left-to-right, but that it should be written in a way that reading it left-to-right makes sense. And a bad example violating it cannot ever demonstrate the invalidity of a general rule to follow (e.g. you cannot disprove the rule "don't kill" by saying that Jack the Ripper has already set a killing precedent).
The Tao of math: The numbers you can count are not the real numbers.
it should be written in a way that reading it left-to-right makes sense
/because/ it is read right-to-left.
Come now. If writing "x == y" makes sense, surely writing "y == x" still makes sense, regardless of what x and y are. I'll go out on a limb here and suggest that if "x x" also makes sense.
you cannot disprove the rule "don't kill" by saying that Jack the Ripper has already set a killing precedent
I can disprove the rule "don't kill" by saying that one is occasionally forced to kill in order to survive, no matter ho immoral killing might be. Similarly, one is occasionally forced to read in a right-to-left style in C, therefor you cannot dismiss a construct simply
But whatever. You can amend your poor analogy by specifying what sort of organism we're killing, to which my response is simple. Comparing programming style to murder is obscene.
It's always a long day... 86400 doesn't fit into a short.
Fucking slashdot. Plain text should mean plain text!
I'll go out on a limb here and suggest that if "x < y" makes sense, then "y > x" also makes sense.
It's always a long day... 86400 doesn't fit into a short.
Unless you immediately follow your read with an "if(!input) break;", your code is likely to have a logic error (it will "read" the last item twice). ITYM /* read from input */ // process the input /* read from input */
// process the input
/supposed/ to code that way. It's the idiomatic way to express a read-until-eof loop in C++ (or C.
while(input) {
}
Though now you have duplicate code. That's why there exists an idiom to avoid it
while(/* read from input */) {
}
Ever wonder why a stream converts to a Boolean? (Well, technically to a pointer, but that's only to avoid integer semantics.) It's because you're
It's always a long day... 86400 doesn't fit into a short.
Actually the code I copied and pasted from did have a break. The read loop was done that way because it was doing something a little different. My trimming removed both of these facts - sorry.
To be honest, I really don't like the "while (input)" because input isn't a boolean. Perhaps I'm being anal, but I think *in general* that leads to my code being robust and more easily understandable and/or maintainable by others.
You would use this only to guard very short sections. If the sections were long, this optimization matter much, anyway. If they are *very* short, eg insert an element into a list, even busy waiting would do. A short sleep timeout obviously wouldn't hurt for cases where multiple threads keep using this section.