Sun Gives Multithreading an RDBMS Feel

Sun is in the process of extending its multithreading support to protect applications and data alike from accidentally stepping on each other and potentially corrupting memory or data.

The solution is hardly unique. It’s the same issue relational database vendors went through 30 years ago. When you have multiple people accessing and modifying the same database, it’s a given that two people will access the same database entry and can overwrite each other.

The same applies in the multithreaded world, only it’s happening in the memory of a server rather than on its hard drives. With multiple threads and applications all running in the same memory space, especially on virtualized servers, it’s inevitable that two applications will try to occupy the same memory space or access the same data.

So Sun (Quote) is taking a cue from the RDBMS crowd. “We have a joke that there isn’t an idea we haven’t ripped off from the RDBMS world for the multithreaded world,” said Mark Moir, senior staff engineer at Sun Labs.

The current solution has been thread locking. A piece of memory or data would be locked by one thread so no others could access it. This means other threads and processes would have to wait, thus slowing down overall servers as more processes are running.

“Transactional memory’s promise is to make all this automatic, to make sure you don’t all interfere with each other. You just write the code to get done and the system makes sure they don’t interfere with each other,” said Moir.

There are different ways to do transactional memory, such as in hardware or in software. Sun has chose to go the hybrid path with a combination of hardware and software fixes. Support for transactional memory will be a part of Sun’s upcoming Rock processor, and it will be a part of Solaris.

This article was first published on InternetNews.com. To read the full article, click here.