I was wondering about transactional memory. Is anyone working on any tools.
I am interested in the subject because It applies to concurent parrallel systems.
The hardware looks very semantical, if we develope tools for such it can only help.
I would be interested in helping anyone along the same lines. Very few archetectures
can only take advantage of software, XCore hardware can. I hope there some people
here that have some experience with this and would elaborate.
Thanks
Transactional memoy?
-
shawn
- XCore Addict
- Posts: 238
- Joined: Thu Dec 17, 2009 5:15 am
-
shawn
- XCore Addict
- Posts: 238
- Joined: Thu Dec 17, 2009 5:15 am
I'm aware this is a tricky subject, but for Xlinkers/Xcore, I pose It as an interesting challenge.
At first this subject, to me, that is, was very dry, like reading a legder. After a while though, it
began making a bit of sense, but I have a lot to learn. It strikes me that this could be applied
to areas of investigation on the G2, G4 in particular. TM just seem's full of potential looking for
some killer apps, perhaps.
Hope this URL gives some, a better clue...
http://mais.uol.com.br/view/v1xaxe2lamb ... 6?types=A&
At first this subject, to me, that is, was very dry, like reading a legder. After a while though, it
began making a bit of sense, but I have a lot to learn. It strikes me that this could be applied
to areas of investigation on the G2, G4 in particular. TM just seem's full of potential looking for
some killer apps, perhaps.
Hope this URL gives some, a better clue...
http://mais.uol.com.br/view/v1xaxe2lamb ... 6?types=A&
-
paul
- XCore Addict
- Posts: 169
- Joined: Fri Jan 08, 2010 12:13 am
I have to say I found this helpful... http://en.wikipedia.org/wiki/Transactional_memory :lol:
It seems to me that transactional memory is actually a very simple concept (unless I have misunderstood) - it simply allows shared memory read/writes without the inherent dangers of something else trying to read/write to the same place and ending up with nasty race conditions etc.
This is not unlike what you get in databases where rows in a table are able to be locked from reading and writing to avoid just this issue.
Implementing this in software on an XCore would require a library and would be nasty to use if it wasn't built into the compiler. Otherwise you build it into the architecture (similar to the Rock sun processor).
It seems to me that transactional memory is actually a very simple concept (unless I have misunderstood) - it simply allows shared memory read/writes without the inherent dangers of something else trying to read/write to the same place and ending up with nasty race conditions etc.
This is not unlike what you get in databases where rows in a table are able to be locked from reading and writing to avoid just this issue.
Implementing this in software on an XCore would require a library and would be nasty to use if it wasn't built into the compiler. Otherwise you build it into the architecture (similar to the Rock sun processor).
Paul
On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
-
jonathan
- Respected Member
- Posts: 377
- Joined: Thu Dec 10, 2009 6:07 pm
Transactional memory does not scale to large numbers of concurrent threads/processes and is incompatible with timing determinism (being an essentially optimistic concurrency mechanism).
I can't see much benefit of implementing it on an XCore (because I can't think of an application that would actually benefit from explicit shared memory that wouldn't suffer from the lack of timing determinism). And implementation across XCores simply won't scale.
It might be an interesting way to implement a shared external data memory for a G4, for example, though?
I can't see much benefit of implementing it on an XCore (because I can't think of an application that would actually benefit from explicit shared memory that wouldn't suffer from the lack of timing determinism). And implementation across XCores simply won't scale.
It might be an interesting way to implement a shared external data memory for a G4, for example, though?
-
shawn
- XCore Addict
- Posts: 238
- Joined: Thu Dec 17, 2009 5:15 am
Thanks Guys,
I see what you mean, TM is more or less a patch for non CSP type systems.
Correct me if i'm wrong, It always needs software and being used to bridge a
communication issue inherient in Classic von neumann machines, they represents
most user systems globally. Therefore TM would be pointless in CSP because CSP
routes around the whole problem, am I correct? I suppose the idea of TM might not
need or be of much virtue within the XCore. That's good!!
Use OpenCL to deal with that kind of abstraction, kinda ; )
I see what you mean, TM is more or less a patch for non CSP type systems.
Correct me if i'm wrong, It always needs software and being used to bridge a
communication issue inherient in Classic von neumann machines, they represents
most user systems globally. Therefore TM would be pointless in CSP because CSP
routes around the whole problem, am I correct? I suppose the idea of TM might not
need or be of much virtue within the XCore. That's good!!
Use OpenCL to deal with that kind of abstraction, kinda ; )