Transactional memoy?

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
User avatar
shawn
XCore Addict
Posts: 238
Joined: Thu Dec 17, 2009 5:15 am

Transactional memoy?

Postby shawn » Thu Feb 11, 2010 9:51 am

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
User avatar
shawn
XCore Addict
Posts: 238
Joined: Thu Dec 17, 2009 5:15 am

Postby shawn » Sun Feb 14, 2010 8:47 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&
User avatar
paul
XCore Addict
Posts: 169
Joined: Fri Jan 08, 2010 12:13 am

Postby paul » Sat Feb 20, 2010 5:22 pm

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).
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.
User avatar
jonathan
Respected Member
Posts: 377
Joined: Thu Dec 10, 2009 6:07 pm

Postby jonathan » Sat Feb 20, 2010 5:51 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?
Image
User avatar
shawn
XCore Addict
Posts: 238
Joined: Thu Dec 17, 2009 5:15 am

Postby shawn » Sat Feb 20, 2010 11:30 pm

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 ; )

Who is online

Users browsing this forum: No registered users and 1 guest