The evolution of customer support

AdiOltean — Sat, 09 Dec 2006 11:12:00 GMT

- 2000 - You call their customer support. “Wait a second – did you actually install an application after installing our sound card? We don’t support this configuration. <hang>” (and that guy will likely get promoted for solving most support calls in record time).

- 2001 – You call their customer support. Nobody answers because the company is out of business due to the .com fallout.

- 2002 – You call their customer support. But you get someone with a think non-English accent which keeps asking you about completely unrelated stuff.

- 2003 – You finally figure out that if you put your problem on the newsgroups you will get help.

- 2004 - You complain about the problem in your blog, and you eventually get suggestions in comments section.

- 2005 - You complain about the problem in your blog, get instant notoriety, and wait for someone from that company to reply in the comments section :-)

- 2006 – You post a video on YouTube with your problem, get instant notoriety, and wait for someone from that company to reply in the comments section.

An example in the last category: Here is a guy describing his problem with the Xbox 360 wireless headset.

http://www.joystiq.com/2006/12/09/todays-hottest-game-video-360-headset-woes/

Today's most-watched YouTube game video shows a gamer who is unable to connect his original Xbox 360 controller and Wireless Headset together on channel one. The demonstration implies that this is a widespread issue with no fix yet from Microsoft, although we haven't had any issues.

The gamer shows the process of activating the headset and having a conflict with his original controller. He then repeats the steps with a new, extra controller and has no problem.

It's like the I-Team without having to sit through the rest of the made-up local news. See the video after the break.

I don't know the solution to his problem, but I notified the XBox team anyway... I hope that they will respond!

[Submit this story to digg.com]

P.S. By the way, for any problems, please call the Microsoft support - they provide an excellent service, (as they always did), won't hang on you :-), and if it is our problem, the call is free.]

Lock-free programming: used now in games!

AdiOltean — Thu, 09 Nov 2006 03:54:00 GMT

Lock-free programming is a performant multi-threaded synchronization technique that allows you to safely manage in-memory data in a controlled manner. In its essence, the idea is to write your multi-threaded programs without using locks. Why is this better? For one thing, using OS constructs like mutexes will sometime induce an additional performance penalty.

For example, the occasional user-mode/kernel-mode transition for acquiring or releasing a lock induces an additional, unpredictable delay in the course of things. This additional delay causes other threads (waiting for the resource) to be delayed as well, causing a cascade effect which in the end slows down the whole program. This special situation is called lock convoy.

The name lock convoy comes from the bottleneck that appears on a highway when a car performs a full stop on a lane. All the cars in the back will stop as well, creating a larger and larger bottleneck. The interesting thing is that the bottleneck continues to stay there for hours even if the original car is long gone.

Lock convoys can be tricky to detect and eliminate in performant code, but lock-free programming is one of the techniques that can be used to eliminate these unpredictable delays. For lock-freep programming, InterlockedCompareExchange( ) is your friend :-)

Are these lock-free techniques used in real life? Yes - mostly in the high-performant, CPU-intensive OS-level code, but in applications as well.

Valve plans to incorporate lock-free programming techniques in the latest Steam engine. These techniques allows you to maximize the CPU usage in multi-core configurations, by avoiding

The approach that Valve finally chose was a combination of the coarse and fine-grained, with some extra enhancements thrown in. Some systems were split on multiple cores using coarse threading. Other tasks, such as VVIS (the calculations of what objects are visible to the player from their point of view) were split up using fine-grained threading. Lastly, whenever part of a core is idle, work that can be precalculated without lagging or adversely affecting the game experience (such as AI calculations or pathfinding) was queued up to be delivered to the game engine later.

Valve's approach was the most difficult of all possible methods for utilizing multiple cores, but if they could pull it off, it would deliver the maximum possible benefits on systems like Intel's new quad-core Kentsfield chips.

[...]

The end results of Valve's efforts were even better than they had initially hoped. Not only was the speedup on the four-core Kentsfield chips nearly linear in most cases (an average of 3.2 times over a single core) but having four CPUs instead of two made it possible to do things that simply couldn't be done with fewer cores.

These new opportunities include greatly increased particle effects. Instead of smoke and explosions being static overlays on top of the game action, programmers can now develop interactive particles, such as smoke that the player can push with his hands, or burning embers that can singe the player if he gets too close. In addition, extra cores could be used for dramatically better AI, or to apply artificial intelligence techniques (like pathfinding) to huge numbers of enemies. Imagine, for example, a Lord of the Rings-type battle, with all the enemies acting independently and intelligently. With enough cores, this sort of thing could be put into a game and take place in real-time.

Antimail : gaming

The evolution of customer support

Lock-free programming: used now in games!