Misinformation is abundant. For instance, I needed a read/write locking mechanism for Windows and was hoping to get some development tips and ran across this as one of the top ten results from Google:
That's all fine and dandy...if you want application performance to, to use a technical term, suck. Performance really goes down the tubes if 10 threads want to write all at once. Every thread wanting to write has to line up and then 1000+ synchronization primitives have to be acquired before the last one can finish writing.
If you are a software developer with less than 5 years of experience and don't know the first thing about a topic, please, please, please do NOT blog on it, do not write an article, do not visit a forum declaring knowledge of it, do pass GO, and do not collect $200. (If anything, you owe the world a formal apology and you owe me $200 for wasting my time). Google and other search engines will pick up your misinformation, spider it, cache it, and spread the misinformation to the uninformed population. Who in turn will think that that is the answer to their question and will blindly redistribute it in an equivalent format - or worse, link to the site with the misinformation - giving it a higher Google ranking.
Some people wonder why applications keep getting slower even though more CPU and RAM are available. This is why. Misinformation is quite abundant and, while there are millions of programmers out there, there are few people knowledgable enough to understand what is wrong, why it is wrong, how it should have been done in the first place, and then be able to accomplish it in a reasonable amount of time. Over time, misinformation builds on itself and now we have programmers who think they are real software developers by reading books that give them warm fuzzies as they put CDs with source code on them into the drive.
For those interested, the solution to the problem of read/write locking involves using a mutex, two events, and four integers that track:
1) How many read locks there are.
2) How many threads want a read lock.
3) Whether or not a write lock is currently executing.
4) How many threads want a write lock.
With those four variables, it is easy to determine what to do - either wait on an event or acquire the lock. When unlocking a write lock, check for other threads wanting a write lock and let them have it (it is still "hard" to obtain a write lock, so once you have it, don't let go), otherwise let those wanting a read lock to have it. Those event objects I mentioned earlier come in handy here. This setup favors letting writers have priority, which can be a problem if there are lots of writes and very few reads. However, read/write locks are supposed to be mostly read operations with few writes. If it is mostly writes, a single mutex is more efficient.
The other difference between the former's misinformation and my real information is that I wrote real code for a read/write locking mechanism while the misinformer states they never even tried it out, but it "should work". Mine actually works, is performance-friendly, and there is real, working code using it. Granted, I didn't publish any of it here (for numerous reasons - some legal), but I did describe it well enough that someone could easily duplicate the effort without too much trouble. Besides, if I displayed code here, it wouldn't teach anyone anything about how a read/write locking mechanism works. People would simply swipe the code and assume it worked properly. Then they would complain to me about problems they are having that wouldn't even be related to read/write locking. I'm not going to hand-hold or wipe noses.
Today we learned that if we are new programmers to not start spouting out information left and right. It is dangerous. And stupid. And tends to come back to haunt us later. We also learned how to develop a real read/write locking mechanism for Windows. Yay for us.
This episode of the Cubicspot blog is brought to you by:
ShareWrap - the only product activation system you will ever need.
The letters W and Z.
And ramen. Everyone loves ramen (especially the Mi Goreng kind - mmmm...large quantities of MSG).