For many software developers, the differences between a mutex and a semaphore is murky at best. This post summarizes and links to several recent articles that clarify the situation.
Archive for the ‘Best practices’ Category
Mutexes and Semaphores
Posted in Best practices on September 24, 2009 | Leave a Comment »
Persisting data in a Real-Time distributed system
Posted in Best practices on June 26, 2009 | Leave a Comment »
Most of the distributed systems we deal with at RTI have performance constraints at their core. Either the system is pushing the limits of the available resources, or the action-reaction timing is critical for a given event. In other words the constraint might be on throughput or latency (or increasingly latency vs. throughput). In these [...]
Thinking Differently About Messaging
Posted in Best practices, Standards on June 3, 2009 | Leave a Comment »
If you’re an old hand at messaging, but new to data distribution, the phrase “data-centric design” may sound like just a new way of describing the same old architectures. But data-centric and message-centric thinking differ in subtle-yet-important ways. Understanding those differences will help you pick the right tool for each job.
Complex Event Processing – Making sense of all your data
Posted in Best practices, Ecosystem on May 27, 2009 | Leave a Comment »
So you have a distributed system and you’re happily sending data between nodes in your system. The consumer applications are consuming the data your producer applications are producing, and everything is running smoothly. Now, that doesn’t sound like any system you know does it? Distributed systems are by nature complex. Nodes and applications are not [...]
Getting Started: The Easy Way
Posted in Best practices, tagged Getting Started on May 21, 2009 | Leave a Comment »
Here at RTI, we take the concept of “Getting Started” to a new level with our Data Distribution Service (DDS) product. With the use of a code generation tool called “rtiddsgen”, new developers can actually create applications that will publish and subscribe their own data types.
Tim – the network tool man – Taylor
Posted in Best practices, tagged Debugging on May 14, 2009 | Leave a Comment »
When I moved to the US a decade ago, Home Improvement was a popular television sitcom, starring Tim Allen as Tim the tool man Taylor, a host of a made up home improvement show.
Among the support team, when we learn about a new debugging tool, we frequently joke about ‘our network debugging tool belt’. Over [...]
Reconsidering Your Priorities
Posted in Best practices on May 11, 2009 | Leave a Comment »
A lot of people who have never used RTI’s infrastructure ask, “How do I prioritize my messages so that more important messages arrive before less important ones?” Yet almost no one worries about that once they’ve actually used our software. The reason is that, in RTI’s broker-free peer-to-peer infrastructure, there are no intermediate message queues to prioritize in the first place.
Be your support engineer’s best friend
Posted in Best practices, tagged Debugging on May 7, 2009 | Leave a Comment »
In my previous post, I detailed two resources for answers to commonly asked questions or to look up specific known issues. Of course that requires you to at last know what to ask or look for. Before getting there you probably want to find out more about how the middleware is doing, or in the [...]
Throughput Performance: Comparing Apples to Apples
Posted in Best practices on May 5, 2009 | 2 Comments »
When evaluating vendors’ reports of throughput performance, it’s important to pay attention to the data size, system architecture, and testing methodology. Without an understanding of these things, you won’t be able to determine whether the reports are relevant to you or to compare different middleware implementations.
Solutions! Solutions! Solutions!
Posted in Best practices, Product news, tagged Debugging on May 1, 2009 | Leave a Comment »
Leading the support team at Real-Time Innovations, I get to experience first hand how our customers are using our middleware. The type of questions range from simple how-to questions to more involved inquiries on recommended ways of implementing a particular communication pattern. And of course there is the occasional defect. In my maiden blog post [...]