Technologies of Tomorrow

It is exciting to look into the future of technology. In an age of continuous innovation and invention, when the discovery of today loses its sheen tomorrow, it is not easy to pinpoint technologies that will transform our future.

Engineering and technical developments are everyone's concern, as they will not be confined to industry, university classrooms, and R&D labs. Instead, they will make a tremendous difference in our day-to-day lives. Here I will attempt to identify some of the technologies that will revolutionize our lives and our values in the coming years.

1. Quantum Computers
Unlike current PCs, quantum computers will have switches that can be in an on or off state simultaneously. The mechanism that will make this possible is known as superposition, and the switches are referred to as quantum bits. The system will make quantum computers operate very fast. A basic quantum computer is likely to be operational by 2020.

2. Programmable Matter
Scientists are in the midst of creating a substance that can take a specific shape to perform a specific task. The substance is known as claytronics, and it consists of catoms. Individual catoms are programmed to move in three dimensions and position themselves so that they assume different shapes. This technology is likely to have numerous applications ranging from medical use to 3D physical rendering. It may take around two decades to become a reality.

3. Terascale Computing
Techies are working on a project that would make our PCs able to contain tens to hundreds of parallel working cores. The device will have the capability to process huge amounts of information. To create this technology, Intel is exploring the possibility of using nanotechnology and allowing for billions of transistors.

4. Repliee Robots
Repliee is one of the most advanced life-like robots ever created. Repliee, an android, is covered with a substance which is very similar to human skin. Sensors placed inside the robot control its movements and enable it to respond to its environment. Astonishingly, the robot can flutter its eyelids and replicate breathing. Repliee operates best in a static condition.

5. Organic Computers
To further advance the computing realm, techies need to create a hybrid CPU that is silicon based but contains organic parts as well. The most promising progress in information processing concerns a neurochip that places organic neurons onto a network of silicon or other materials. Future computers will be able to bridge the silicon and organic spheres to utilize processors that incorporate both of these elements.

6. "Spray-On" Nanocomputers
The "spray-on" nanocomputer would consist of particles that can be sprayed onto a patient. It would monitor the patient's medical condition and communicate wirelessly to other machines.

7. Carrier Ethernet
Carrier Ethernet is a business service/access technology. It can serve as a transport method for both business and residential service. Ethernet will dominate the metro space in the future and will slowly displace SONET/SDH over the next 10 to 20 years.

Development sustains life. However, techies cannot afford to forget that technological advancement will remain inadequate in the absence of contributions from all branches of knowledge and will not flourish if it does not benefit society.

Multiprocessor Semaphore

Shared memory semaphores are basic tools for interprocessor synchronization. Although
self-imposed design constraints can often reduce synchronization requirements, semaphores offer significant flexibility to multiprocessor system designers. The implementation presented here illustrates some fundamental issues of multiprocessor concurrency and demonstrates the tremendous value of a multitasking OS like DSP/BIOS.
Many variations on this theme are possible. Most obviously, we can modify the semaphore to handle multiple tasks on one processor or tasks on more than two processors. And because our wait operation handles notification interrupts and task wake-up, we can implement any scheduling policies that make sense for more generalized versions.

MULTIPROCESSOR SEMAPHORE
==============================================
Multiprocessing architectures are becoming pervasive. DSPs are widely used in dense multiprocessor arrangements at the network edge, and systems-on-chip often include DSP cores to accelerate math-intensive computation. Although DSP/BIOS provides a standard, efficient, robust API for uniprocessor applications, we sometimes encounter situations where interprocessor synchronization mechanisms would be very useful. Here we will take a look at multiprocessor mutual exclusion and we will talk about new method to implement interprocessor semaphores using DSP-BIOS.
Many multiprocessor DSP systems are designed to share a physical pool of memory in the sense that each processor sees the memory as directly addressable - a DSP shares a region of memory with a host processor or other DSPs-.
A common architecture uses a large region of single-port RAM shared by all devices, including the host. Although arbitration issues complicate hardware design. A second architecture uses of dual-port RAM between processors. The downside here is the relatively high cost and small storage capacity of these devices - large banks of expensive DPRAM are seldom practical. But in applications that use segmented data transport or small data sets where small amounts of DPRAM are sufficient, this method is very useful. DPRAM is relatively fast, designer-friendly and, unlike FIFOs, can store shared data structures used for interprocessor communication.
We need to remember this when using shared memory. When processors have on-chip cache or a system uses write posting, software designers must pay attention to shared variable coherence. Depending on the processor, programmers can disable cache, use cache by-pass, or flush cache to ensure that a shared location is in a proper state. The cache control API in TI's comprehensive Chip Support Library, for example, provides an ideal tool for cache subsystem management. Solutions to write-post delay problems are system-specific.
Our discussion here assumes that two processors use a common shared memory buffer to pass data or to operate cooperatively on a data set. In either case, one or more tasks on the processors might need to know the state of the buffer before accessing it, and possibly to block while the buffer is in use. As in the case of single-processor multitasking, we need a mutual exclusion mechanism to prevent inappropriate concurrent operations on the shared resource. Let's start with a quick review of mutual exclusion to better understand multiprocessor issues.
Shared resource management is a fundamental challenge of multitasking. A task (or thread, or process) needs the ability to execute sequences of instructions without interference so it can atomically manipulate shared data. These sequences, known as critical sections, are bracketed by entry and exit protocols that satisfy four properties - mutual exclusion, absence of deadlock, absence of unnecessary delay and eventual entry (no starvation). Our focus here is mutual exclusion - the remaining properties are detailed in any number of textbooks and will be satisfied by our multiprocessor semaphore.
Relative to a shared resource, mutual exclusion requires that only one task at a time execute in a critical section. Critical section entry and exit protocols use mechanisms such as polled flags (often called simple locks or spin locks) or more abstract entities such as blocking semaphores. Simple locks can be used to build protection mechanisms of greater complexity.
B-Semaphore
The semaphore is a system-level abstraction used for interprocess synchronization. It provides two atomic operations, wait (P) and signal (V), which are invoked to manipulate a non-negative integer within the semaphore data structure. The wait operation checks the value of the integer and either decrements it if positive or blocks the calling task. The signal operation either unblocks a task waiting on the semaphore or increments the semaphore if no tasks are waiting. A binary semaphore, with value limited to 0 and 1, can be used effectively by an application to guard critical sections.
A multiprocessor semaphore can be implemented by placing its data structure in shared memory and using RTOS services on each processor to handle blocking. Before outlining an implementation, let's look at two aspects of semaphores that cause complications in a multiprocessor environment. One is low-level mutual exclusion to protect shared data within a semaphore and the other is wake-up notification when a semaphore is released.
Low-level mutual exclusion
At its core, a semaphore has a count variable and possibly other data elements that must be manipulated atomically. System calls use simple mutual exclusion mechanisms to guard very short critical sections where the semaphore structure is accessed. This prevents incorrect results from concurrent modification of shared semaphore data.
In a uniprocessor environment, interrupt masking is a popular technique used to ensure that sequential operations occur without interference. Interrupts are disabled at the entrance to a critical section and re-enabled on exit. In a multiprocessor situation, however, this isn't an option. Even if one processor could disable the interrupts of another (rarely the case), the second processor would still execute an active thread and might inadvertently violate mutual exclusion requirements.
A second technique uses an atomic test-and-set (or similar) instruction to manipulate a variable. This variable might be the semaphore count itself or a simple lock used to guard critical sections where semaphore data is accessed. Either way, a specialized instruction guarantees atomic read-modify-write in a multitasking environment. Although this looks like a straightforward solution, test-and-set has disadvantages in both uniprocessor and multiprocessor scenarios. One drawback is dependence on machine instructions. These vary across processors, provide only a small number of atomic operations and are sometimes unavailable. A second problem is bus locking. If multiple processors share a common bus that doesn't support locking during test-and-set, processors might interleave accesses to a shared variable at the bus level while executing seemingly atomic test-and-set instructions. And a third problem is test-and-set behavior in multi-port RAM systems. Even if all buses can be locked, simultaneous test-and-set sequences at different ports might produce overlapped accesses.
Now consider two approaches that are very useful in shared memory scenarios. One relies on simple atomic hardware locks and the other is a general-purpose software solution known as Peterson's algorithm.
Hardware flags
In shared memory systems, hardware-assisted mutual exclusion can be implemented with special bit flags found in multi-port RAMs. DPRAM logic prevents overlap of concurrent operations on these hardware flags, forcing them to maintain correct state during simultaneous accesses. And because processors use standard-issue read/write instructions to manipulate the flags, special test-and-set-like instructions are not required. But this is still a limited solution - software engineers often encounter shared memory systems that lack this feature. So let's take one more step to arrive at a general-purpose hardware-independent method.
Peterson's Algorithm
Peterson's algorithm, published in 1981, provides an elegant software solution to the n-process critical section problem and has two distinct advantages over test-and-set spin locks. One is that atomic test-and-set is not required - the algorithm eliminates the need for special instructions and bus locking. The other is eventual entry - a task waiting for entry to a critical section won't starve in a weakly fair (typical) scheduling environment. Although Peterson's algorithm looks deceptively simple, it's a culmination of many attempts by researchers to solve the critical section problem.
The following pseudo-code shows the entry and exit protocols used to enforce two-process mutual exclusion. Note that Peterson adds a secondary "turn" variable - this prevents incorrect results from race conditions and also ensures that each waiting task will eventually enter the critical section.
Listing 1: Peterson's Algorithm
initialization
P1_wants_entry = P2_wants_entry = FALSE
turn = P1
task P1
P1_wants_entry = TRUE /* set lock */
turn = P2 /* grant turn to other task */
loop while (P2_wants_entry and turn == P2) /* buzz waiting for lock */

critical section /* execute critical section */

P1_wants_entry = FALSE /* release lock */
task P2 /* same logic as P1 */
P2_wants_entry = TRUE
turn = P1
loop while (P1_wants_entry and turn == P1)
critical section
P2_wants_entry = FALSE
We can easily imagine situations where more than two processes try to enter their critical sections concurrently. Peterson's algorithm can be generalized to n processes and used to enforce mutual exclusion between more than two tasks. And other n-process solutions, such as the bakery algorithm, are readily available in computer science textbooks. Our discussion here is limited to the two-process case only for clarity and brevity. Pseudo-code for the n-process Peterson algorithm can be found on the Electric Sand web-site.
Blocking mechanism
Now that we have a low-level mutual exclusion tool to safely manipulate shared data within a semaphore, consider the other key ingredient of semaphores, blocking. Assuming that each processor runs DSP/BIOS or another multitasking OS, we develop our wait operation using services that are already available on each individual processor. DSP/BIOS provides a flexible semaphore module (SEM) that we use in our implementation.
When the owner of a uniprocessor semaphore releases it with a signal system call, the local scheduler has immediate knowledge of the signal event and can unblock a task waiting on the semaphore. In contrast, a multiprocessor semaphore implies that the owner and the requestor can reside on different processors. Because a remote kernel has no implicit knowledge of signal calls to a local kernel, the remote kernel needs timely notification of local signal events. Our solution uses interprocessor interrupts to notify other processors of local activity involving a shared semaphore.
Semaphore implementation
This implementation of a multiprocessor binary semaphore (MBS) assumes that the hardware supports interprocessor interrupts and that a task won't try to acquire a semaphore while another task on the same processor owns it. The latter restriction simplifies the example and can easily be removed with some additional design work.
The wait operation
MBS_wait is invoked to acquire a shared memory semaphore. If the semaphore is available, MBS_wait decrements it and continues. If the semaphore is already owned, the requestor task blocks within MBS_wait until a release notification interrupt makes it ready-to-run. Once the interrupt occurs and higher priority tasks have relinquished the CPU, the task waiting on the semaphore wakes up within MBS_wait and loops to re-test it. Note that the task doesn't assume ownership immediately when unblocked. Because a remote task might re-acquire the semaphore by time the requestor wakes up, MBS_wait loops to compete for the semaphore again.
When MBS_wait determines that a semaphore is unavailable, it sets a notification request flag in the shared semaphore data structure to indicate that the processor should be interrupted when the semaphore is released elsewhere in the system. To avoid a race condition known as the lost wake-up problem, MBS_wait atomically tests the semaphore and sets the notification request flag if the semaphore is unavailable.
Code for the wait operation is divided into two distinct parts. MBS_wait contains the blocking code and is called by an application. MBS_interrupt runs in response to the notification interrupt and posts a local signal to the task waiting on the semaphore. This is very similar to a device driver model, where the upper part of a driver suspends a task pending I/O service and the interrupt-driven lower part wakes it up.
The signal operation
MBS_signal releases a semaphore by incrementing its value and posting an interrupt to a processor that requested release notification. This causes MBS_interrupt to execute on the remote processor where a task is blocked on the semaphore. Note that this varies slightly from the uniprocessor signal operation described earlier where the semaphore is incremented only if no tasks are blocked.

Pseudo-code
Now that we have a notion of shared semaphore architecture, let's look at pseudo-code describing the wait and signal operations. Keep in mind that this example applies to a two-processor version where only one task at a time on each processor tries to acquire the semaphore. General implementations servicing more processors and sharing the semaphore between multiple tasks on each processor can be implemented by using the n-process Peterson algorithm and modifying the MBS operations.
Note that the critical sections, enforced by Peterson's algorithm (Peterson entry and Peterson exit), are very short instruction sequences used to manipulate the semaphore data structure. The details of Peterson's algorithm are not shown - these are implicit in the Peterson entry/exit operations. The lock and turn variables used in Peterson's algorithm are distinct from the semaphore data elements accessed in the critical sections.
The critical sections are preceded with DSP/BIOS TSK_disable calls to prevent task switching. A task switch during a critical section could cause another processor to spin indefinitely in Peterson entry if it tries to acquire the same semaphore. The critical sections should be executed as quickly as possible.
Also note that the example omits error checking, return values and timeouts. The pseudo-code is meant to highlight discussion topics rather than provide a detailed implementation template.

MBS_wait () {
success = FALSE /* local variable, not part of semaphore */
while (success == FALSE) { /* repeat semaphore acquisition attempt */
TSK_disable () /* prevent DSP/BIOS task switch */
Peterson entry /* Peterson's entry protocol */
/* critical section begins */
if (sem_value > 1) {
sem_value = sem_value - 1
success = TRUE
}
else {
notification_request = TRUE
}
Peterson exit /* end critical section */
TSK_enable () /* re-enable DSP/BIOS scheduler */
if (success == FALSE) { /* local variable shows result */
SEM_pend () /* sleep using DSP/BIOS semaphore */
}
}
}
MBS_interrrupt {
SEM_post () /* local wake-up signal using DSP/BIOS */
}
MBS_post () { /* release the semaphore */
TSK_disable ()
Peterson entry

/* start critical section */

sem_value = sem_value +1; /* increment the semaphore */
if (notification_request == TRUE) { /* notify a remote task? */
send notification interrupt /* yes - send an interrupt */
}
Peterson exit /* end critical section */
TSK_enable ()
}

Why Data Loss ?!===> Hw or System Malfunction

We understand what happens when the information you have been storing for keeps suddenly becomes inaccessible.

When you lose the information, which was once accessible is referred as data loss.
The threats to data loss may come in many different forms, from a simple mistake to a massive natural disaster
Since, we now know what data loss is; let us read on to find out as to what causes data loss to occur and what measures do we need to follow in order to prevent that from happening.

Hardware or System Malfunction

The biggest factor leading to data loss is hardware malfunction or hard disks failure. It is known that 44% of all data losses are an outcome of hardware or system malfunction. Hard disks are mechanical devices and therefore are more prone to wear and tear. It is believed that the estimated average life of a hard disk is 3 years. Hardware fails to function properly due to one of the following reasons:

(a) Head/Media Crash: Head/media collisions account for a large percentage of hardware malfunctions.

Picture this: a series of hard disk platters rotating at the rate of 150 times per second with heads being separated (at submicron distances), moving over them. Even the slightest of disturbance inside the disk could cause the entire disk to stop functioning properly. When the read/write head touches the rotating platter of a hard disk, it leads to head crash.

When even the smallest bit of dust enters the sealed drive unit and settles on magnetic surfaces, it gets stuck in the thin gap between the head and the disk.

Dropping a disk to the floor may also cause hard disk malfunction. Not only this, even the slight jerk or vibration can unsettle alignments and lead to hardware malfunction.

(b) Sudden catastrophic failure: When you cannot detect the presence of the hard drive in the CMOS setup or when the operating system doesn’t locate the hard drive, it’s logical to think that the data loss has occurred. This POST failure results in hard drive to become inactive. This is when you hear the clicking noise from the hard drive. Sudden temperature variations may directly influence the data loss to occur.

(c) Electrical Failure: Another issue ultimately resulting in the loss of information is electrical failure, which can occur any time. Electrical failure is the direct effect of the circuit board failure, which is located on the bottom of the hard drive. A faulty component, electro-static discharge, damaging circuitry during installation are some of the various causes leading to electrical failure. It is important to keep the system clean and well ventilated; otherwise, it may cause electrical components to fail functioning properly. Hence, it is recommended to keep the system in cool conditions.

(d) Controller Failure: When you try to boot the system but instead receive an error message displaying “HDD Controller Failure”, then be prepared for the loss of your precious data. Yes, this is another reason for data loss to have occurred.

Hard disk controller failure occurs due to one of the following reasons:

• When the adapter is not firmly seated in the slot.
• Failing CMOS battery or accidental user intervention resulting in incorrect data in CMOS setup.
• When IRQ conflicts with other devices.
• When the IDE drives are not mastered/slaved properly.
• MBR (Master Boot Record) or the partition table is distorted.
• When the IDE drives (installed with master and slave) are incompatible.
• When Hard disk drive is not connected or set up properly.
• When the hard drive cable has gone bad (loose, twisted or has a broken wire).
• When the hard drive or the motherboard has gone bad.

When you notice the following changes taking place with your system, prepare yourself for the attack called “data loss”.

• Hard drive stops spinning.
• You receive an error message stating that the device is not being recognized by the system.
• You are unable to access the information, which you could previously.
• When you hear the scraping or rattling sound from the system.
• You system or the hard drive suddenly stop functioning.

This is what you could do in order to avoid the above-mentioned changes taking place:

• Connect your system to a UPS (Uninterrupted Power Supply), in order to protect your system against power surges, which is the main cause of electrical failures.
• Keep your computer in a dry and shaded room, which is clean and free of dust.
• Head crash is one of the most common hardware failures resulting in data loss. It is recommended not to shake the hard drive or avoid giving jerks to the computer, since the slightest of the jerk may result in a head crash or misalignment of platters. It is strictly advised not to remove the casing on the hard drive.

However if Data Loss occurs, Don't Panic. Call [url=spam.spam]Data Recovery Specialist for the Data Recovery Service[/url].
Stellar Information Systems Ltd., a company with over a decade of experience in [url=spam.spam]data recovery software[/url] & services, has an ultra-modern Class-100 clean room facility in Gurgaon. Stellar’s Data Recovery Services (DRS) division operates from this environmentally controlled dust-free area to ensure safe and effective recovery from damaged hard disks.

Storage Consolidation Hurdles for India

A consistent challenge within the IT organization in 2007 is the need to keep cost down. Management is not asking IT not to spend money - but to spend it like nothing more is coming. In other words, spend where it will bring the most benefit in the shortest possible time.

So should you wonder then that a recent survey of IT practitioners across India showed exactly this market condition?

Referring to chart 1, 64 percent of companies surveyed say they are expanding to new markets and new geographies. Second in the list of business concerns is competition. About 57.1 percent say that competition is a constant worry for them, both in the current markets where they are and in the new markets they are eyeing to penetrate or already entering.

In the process of expanding, engaging new potential customers, and staving off competition, companies must keep close watch over how they spend their limited resources. Prudent spending in the face of competition and the need to keep growing revenue to demonstrate shareholder value is pushing 56.7 percent to constantly monitor cost.

Closely trailing these top 3 concerns is the imperative to raise productivity with 53.9 percent continually looking for ways to raise productivity.

Top IT Challenges in 2007-2008

The issues facing IT managers reflect the business concerns of their companies. Because any failure on the part of IT is a showstopper, IT managers put security (52 percent) as their number one priority (see chart 2).

The second (48.3 percent) and fourth (40.4 percent) challenges are related. The rapid proliferation of new and emerging technologies coupled with the imperative to keep costs down means that IT must be sure about what where IT investments are going. The old adage "no one gets fired for buying IBM" is no longer valid. The IT management chain (top to bottom) share the responsibility of ensuring that the right choice is made each time.

The perennial shortage of qualified staff ranks as the third IT challenge among companies in India with 45.2 percent claiming that keeping qualified staff is just as difficult as finding them.

Current IT Initiatives in Place

In a bizarre twist of fate, the top three IT initiatives currently in place are all about availability. Close to 75 percent of respondents say they have a backup/restore strategy in place. Security comes a close 72.7 percent. Because business continuity often involves other departments or business units, the third most deploy IT initiative (business continuity and disaster recovery) is a distant 47.4 percent.

Wireless connectivity bested network storage by 0.2 percent as the fourth most commonly deployed IT initiative at 44.8 percent.

Business benefits of Storage Consolidation

How easy is it to explain to a non-technical person the merits of migrating from a proprietary platform to one that supports Open standards? In the same token explaining the complexity of consolidating storage and servers to the uninitiated (and possibly uninterested) presents a challenge in itself.

That said, 57.6 percent of IT respondents say that simplifying the management of the data center is the number one benefit that can be derived from a storage consolidation exercise.

This is followed by 53.4 percent seeing an improvement in service levels to users as data becomes centralized. This signals IT's understanding that customer satisfaction is an important part of their mandate.

One of the biggest selling points of storage consolidation (and the whole premise behind the success of network attached storage and storage area network) is the idea of storage underutilization and server proliferation. In the days when the only option is direct attached storage, companies would buy additional servers because the server has reached its storage limits.

Storage consolidation allows for companies to buy additional storage without increasing the number of servers on the data center. Survey respondents put better storage utilization as the third most important benefit of consolidation with 52.5 percent affirming this.

The fourth most important benefit (42.2 percent) is a strong selling point to both technology and business managers - the idea of standardizing on specific technologies and processes. By standardizing on a few instead of many, companies are able to simplify the management of their infrastructure.

Why Say NO to Consolidation?

You start to wonder with all the benefits of storage consolidation, why would companies choose to ignore this path? Over 70 percent of respondents listed "limited understanding of the technology and its benefits" as the single biggest hindrance to agreeing to consolidate their storage infrastructure.

This correlates to lack of in-house expertise as the second most cited reason (63.8 percent) for not taking the consolidation path.

Any storage consolidation project will involve costs, from redesigning the data center, to migrating content hosted on siloes of compute servers onto storage-only platforms. With concerns over keeping cost down, it is no surprise that "perceived high project cost" is third on the list at 59.7 percent.

Lack of standards (49.2 percent) and Lack of management support (42 percent) round out the objections to undertaking a storage consolidation exercise.

Profile of Respondents

The respondents to the survey represent mid to senior IT managers working for large enterprises in the India. Enterprise Innovation received 631 responses majority. While only 24.9 percent point to their role as being the final decision maker with regards to storage strategies and acquisitions, 32.8 percent influence the choices made by their company. A further 25.8 percent evaluate the technologies from which decisions are made. As expected only 16.5 percent point to external forces as guiding any storage acquisition indicating the level of trust management places on local talent.

Predicting what you need in the future is always a challenge. This is more acute when it comes to storage. While IT has no problem projecting the server computing requirements based on ongoing and future IT projects, storage requirements are often dictated by how successful campaigns are as well as target audience.

When a global bank launched its first online IPO product in Hong Kong, it quickly realized that it underestimated its storage requirements forcing the bank to review future storage purchase.

This reflects the changing market dynamics. In the survey close to 30 percent of respondents have no idea as to when their next storage purchase will be. But 58.6 percent believe that they have to purchase new storage within a 12-month window.