chris128
Sep 2nd, 2009, 10:49 AM
STM.NET - http://msdn.microsoft.com/en-gb/devlabs/ee334183.aspx
Anyone played with it? The concept sounds good to me - I hate threading issues and SyncLocks and Mutexes etc.
Basically from what I understand, if you had a program where a shared object is accessed from multiple threads at the same time, instead of having to SyncLock or whatever and choose what to lock on etc you would simply stick this at the start of the code that needs to be isolated so that it can only run in one thread at a time:
Atomic.Do()=>
Apparently it provides much more than just a replacement for SyncLock but I havent really delved into the details yet, was just wondering if anyone else has had a look at this and what they thought?
EDIT: Here is Microsoft's description of why they are creating this technology (taken from http://download.microsoft.com/download/9/5/6/9560741A-EEFC-4C02-822C-BB0AFE860E31/STM_User_Guide.pdf):
By now you’d be hard-pressed to find anyone in the industry who hasn’t heard about the coming crisis in software performance. The rate of increase in processor speed has slowed dramatically and is nowhere near the doubling of speed that we saw every two years during the last twenty years.
That’s the bad news; the good news is that Moore’s law is by no means dead. The hardware industry is still able to follow the path that Moore predicted. The density of transistors, in an integrated circuit, still doubles every two years. The industry has, however, run out of effective ideas for turning those transistors into faster processors. Therefore, they are using the extra transistors to create more processors, building chip multiprocessors (CMP) with many processors on a single chip. Those chips are also known as multi-cores, or many-cores.
This is difficult news for the software industry. We can no longer add new features to our applications and rely on increasing hardware capacity to make evermore complex software perform acceptably. To state things more positively, we can also no longer rely just on better hardware to bring applications that were too expensive in the past to become feasible today (as was the case with, for example, speech recognition). Now, to take advantage of future hardware capacity, we have to fundamentally change the way we program, to exploit the parallel capacity of this new hardware.
Parallel programming is notoriously difficult. Researchers have been working for decades on systems to make parallel programming easier, yet despite these efforts, parallel programming has not yet become popular with all developers. Some amount of skepticism about whether we’ll succeed now is therefore justified – but note that in the past parallel programming was a niche market, if only because of the expense of multiprocessor computers. The hardware industry has the capability to produce chip multiprocessors whose core counts double in time-frames similar to those we have been used to for processor speeds – whether they will do so depends on whether anyone will buy them which, in turn, depends on whether there is any software that utilizes their power to do interesting things that couldn’t be reasonably done on a single-processor machine. If we succeed in creating such software, the virtuous cycle of new hardware and software features and applications will continue.
In order to enable this virtuous cycle Microsoft is making an effort to make effective parallel programming easier. There are many competing ideas on how this might be accomplished. Some are fairly radical: “get everyone to use pure functional languages,” for example. Here we focus on one of these ideas, Transactional Memory. Compared to some other ideas in this space, it is evolutionary rather than revolutionary; programming with transactions will feel fairly similar to programming today, just simplified.
Chris
Anyone played with it? The concept sounds good to me - I hate threading issues and SyncLocks and Mutexes etc.
Basically from what I understand, if you had a program where a shared object is accessed from multiple threads at the same time, instead of having to SyncLock or whatever and choose what to lock on etc you would simply stick this at the start of the code that needs to be isolated so that it can only run in one thread at a time:
Atomic.Do()=>
Apparently it provides much more than just a replacement for SyncLock but I havent really delved into the details yet, was just wondering if anyone else has had a look at this and what they thought?
EDIT: Here is Microsoft's description of why they are creating this technology (taken from http://download.microsoft.com/download/9/5/6/9560741A-EEFC-4C02-822C-BB0AFE860E31/STM_User_Guide.pdf):
By now you’d be hard-pressed to find anyone in the industry who hasn’t heard about the coming crisis in software performance. The rate of increase in processor speed has slowed dramatically and is nowhere near the doubling of speed that we saw every two years during the last twenty years.
That’s the bad news; the good news is that Moore’s law is by no means dead. The hardware industry is still able to follow the path that Moore predicted. The density of transistors, in an integrated circuit, still doubles every two years. The industry has, however, run out of effective ideas for turning those transistors into faster processors. Therefore, they are using the extra transistors to create more processors, building chip multiprocessors (CMP) with many processors on a single chip. Those chips are also known as multi-cores, or many-cores.
This is difficult news for the software industry. We can no longer add new features to our applications and rely on increasing hardware capacity to make evermore complex software perform acceptably. To state things more positively, we can also no longer rely just on better hardware to bring applications that were too expensive in the past to become feasible today (as was the case with, for example, speech recognition). Now, to take advantage of future hardware capacity, we have to fundamentally change the way we program, to exploit the parallel capacity of this new hardware.
Parallel programming is notoriously difficult. Researchers have been working for decades on systems to make parallel programming easier, yet despite these efforts, parallel programming has not yet become popular with all developers. Some amount of skepticism about whether we’ll succeed now is therefore justified – but note that in the past parallel programming was a niche market, if only because of the expense of multiprocessor computers. The hardware industry has the capability to produce chip multiprocessors whose core counts double in time-frames similar to those we have been used to for processor speeds – whether they will do so depends on whether anyone will buy them which, in turn, depends on whether there is any software that utilizes their power to do interesting things that couldn’t be reasonably done on a single-processor machine. If we succeed in creating such software, the virtuous cycle of new hardware and software features and applications will continue.
In order to enable this virtuous cycle Microsoft is making an effort to make effective parallel programming easier. There are many competing ideas on how this might be accomplished. Some are fairly radical: “get everyone to use pure functional languages,” for example. Here we focus on one of these ideas, Transactional Memory. Compared to some other ideas in this space, it is evolutionary rather than revolutionary; programming with transactions will feel fairly similar to programming today, just simplified.
Chris