On Jul 10, 3:59 pm, speedplane <michael.san...@gmail.com> wrote:
[]
>
> Jeez... I hate these newsgroups. Not only is everyone condescending,
sometimes.
> they're also wrong.
I've always been willing to be shown how I am wrong but in this case,
you comments later lead me to see we are talking different
environments - me: embedded and similar applications, you: massively
parallel applications. Different situations, different solutions
needed.
> ... I'm not going to explain this any further.
Sorry you want to walk away mad. All I can say is I think your
original explanation left too many hidden assumptions, so I thought
your were not as knowledgable as you might be. There can be a lot of
context left out in these discussions. I do appreciate the links, and
I'll review them.
> ... If you
> are interested in transactional programming please read the
> literature:
>
> Here's some info on a possible hardware implementation. It goes into
> detail about the copy stage (part 2) and the checking stage (part 3).
> A quick answer to part 3 is that they use a broadcasting system.
> L. Hammond, V. Wong, M. Chen, B. Carlstrom, J. Davis, B. Hertzberg, M.
> Prabhu, H. Wijaya, C. Kozyrakis, and K. Olukotun Transactional Memory
> Coherence and Consistency International Symposium on Computer
> Architecture(ISCA), 2004http://www.cs.ucsb.edu/~arch/cs254/papers/tcc.pdf
>
> If you're more interested in how this effects performance /
> programmability read about the ATOMOS transactional programming
> language.
> B. Carlstrom, A. McDonald, H. Chafi, J. Chung, C. Minh, C. Kozyrakis,
> K. Olukotun The ATOMOS Transactional Programming Language Proceedings
> of the Conference on Programming Language Design and Implementation
> (PLDI), June 2006http://www.cs.ucsb.edu/~arch/cs254/papers/atomos.pdf
>
> Those two papers will explain the basic concepts of transactional
> programming and you'll soon realize that it is different from ORACLE
> database transactions. Indeed special hardware is indeed not needed,
> but transactional programming may make designing massively parallel
> processors more feasible.
Different contexts, different solutions needed. Since this group is
comp.realtime, you can forgive me not thinking about massively
parallel applications during discussions, can't you? (90% of my
efforts nowadays are DB related, so that comes to mind easily.)
Oh well, have a nice day.
Ed
Reply by CBFalconer●July 10, 20072007-07-10
speedplane wrote:
> On Jul 10, 11:41 am, Ed Prochak <edproc...@gmail.com> wrote:
>> "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
>>> speedplane <michael.san...@gmail.com>:
>>
... snip ...
>>
>>>> The main advantage to transactions is that they are really
>>>> easy to program and its virtually impossible to deadlock them
>>>> or cause race conditions.
>>
>> You silly boy. Even the holy Oracle DBMS can get these errors.
>> Race conditions are easy:
>> task A: update tableX set xcounter=xcounter + 1;
>> task B: update tableX set xcounter=xcounter + 1;
>> task A: commit;
>> task B: commit;
>> is the net effect an increase of 2 or 1?
>>
>> locks are harder but still possible in such a transaction design.
>>
>>>> The main disadvantage is that they are very hard to implement
>>>> in non-database systems and will probably require specialized
>>>> hardware.
>>
>> I do not know what special hardware would be needed. Oracle and
>> other DBMS products using this approach seem to run just fine
>> on currrent hardware. What opcode instruction would you want to
>> support this, speedplane?
>
> Jeez... I hate these newsgroups. Not only is everyone
> condescending, they're also wrong. I'm not going to explain this
> any further. If you are interested in transactional programming
> please read the literature:
On Jul 10, 11:41 am, Ed Prochak <edproc...@gmail.com> wrote:
> On Jul 9, 4:37 am, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
>
>
>
> > Op Fri, 06 Jul 2007 22:33:57 +0200 schreef speedplane
> > <michael.san...@gmail.com>:
>
> > > On Jul 6, 9:34 am, Ed Prochak <edproc...@gmail.com> wrote:
> > >> On Jul 6, 4:39 am, speedplane <michael.san...@gmail.com> wrote:
> > >> > On Jul 5, 11:58 pm, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
>
> > > Message passing protocols can very easily have deadlocks and race
> > > conditions. I have to deal with them all the time. One simple type of
> > > message is sending a signal to another thread/application. If the
> > > protocol is complex and the threads/apps are sending signals to each
> > > other all the time, then you have to be prepared to handle many
> > > different types of ordering between the two threads.
>
> > Are you talking about synchronous (e.g. Unix signals) or asynchronous
> > (queued) messages?
>
> Well I certainly was thinking queued messages.
>
>
>
> > > < Passing messages have no need to "suffer from deadlocks
> > > < and race conditions" in a well designed interface
>
> > > I think the key to your statement is "well designed interface".
> > > Designing a good interface for a complex system is by no means easy.
> > > In fact it may be one of the hardest parts of the entire project.
>
> > And it should a hard part, as a lot of other things should be easy when
> > the interface is done right.
>
> And the issue of being "done well" is to use the message passing
> features of the OS. Even small micro kernals have that feature
> usually. Why reinvent such fundamental functionality?
>
>
>
> > > Transactions are commonly used in databases to do processing on the
> > > database atomically. There are a couple steps to a transaction in a
> > > database:
> > > 1) the hardware and/or software creates a small copy of the database
> > > which it is going to modify
>
> copy the whole DB? in hardware? what CPU are you using??
>
> > > 2) It then does all of the processing on that mini-database
>
> So how did the database suddenly become smaller?
>
> > > 3) Once its done it checks to see if any other transaction modified
> > > the memory in that mini-database
>
> and how does it do that without some locking mechanism?
>
> > > 4.a) If no one modified the original memory, then it commits its work
> > > and the transaction completes.
> > > 4.b) If another transaction modified that memory then it discards its
> > > work and depending on the implementation either goes back to 1, or
> > > returns some error.
>
> The other solution is to commit if the user commands it. If there is
> another transaction, it is working on its own copy of the data, so no
> need to not write out the changes.
>
> What you describe is one solution to transactions and deadlocking.
> Oracle for example calls it Multiversioning. (Well to be fair, theirs
> copies the unchanged data, allows the writes to happen, and discards
> the copy of the old data on commit.)
>
>
>
> > > The main advantage to transactions is that they are really easy to
> > > program and its virtually impossible to deadlock them or cause race
> > > conditions.
>
> You silly boy. Even the holy Oracle DBMS can get these errors. Race
> conditions are easy:
> task A: update tableX set xcounter=xcounter + 1;
> task B: update tableX set xcounter=xcounter + 1;
> task A: commit;
> task B: commit;
> is the net effect an increase of 2 or 1?
>
> locks are harder but still possible in such a transaction design.
>
> > > The main disadvantage is that they are very hard to implement in non-
> > > database systems and will probably require specialized hardware.
>
> I do not know what special hardware would be needed. Oracle and other
> DBMS products using this approach seem to run just fine on currrent
> hardware. What opcode instruction would you want to support this,
> speedplane?
Jeez... I hate these newsgroups. Not only is everyone condescending,
they're also wrong. I'm not going to explain this any further. If you
are interested in transactional programming please read the
literature:
Here's some info on a possible hardware implementation. It goes into
detail about the copy stage (part 2) and the checking stage (part 3).
A quick answer to part 3 is that they use a broadcasting system.
L. Hammond, V. Wong, M. Chen, B. Carlstrom, J. Davis, B. Hertzberg, M.
Prabhu, H. Wijaya, C. Kozyrakis, and K. Olukotun Transactional Memory
Coherence and Consistency International Symposium on Computer
Architecture(ISCA), 2004
http://www.cs.ucsb.edu/~arch/cs254/papers/tcc.pdf
If you're more interested in how this effects performance /
programmability read about the ATOMOS transactional programming
language.
B. Carlstrom, A. McDonald, H. Chafi, J. Chung, C. Minh, C. Kozyrakis,
K. Olukotun The ATOMOS Transactional Programming Language Proceedings
of the Conference on Programming Language Design and Implementation
(PLDI), June 2006
http://www.cs.ucsb.edu/~arch/cs254/papers/atomos.pdf
Those two papers will explain the basic concepts of transactional
programming and you'll soon realize that it is different from ORACLE
database transactions. Indeed special hardware is indeed not needed,
but transactional programming may make designing massively parallel
processors more feasible.
Reply by Ed Prochak●July 10, 20072007-07-10
On Jul 9, 4:37 am, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
> Op Fri, 06 Jul 2007 22:33:57 +0200 schreef speedplane
> <michael.san...@gmail.com>:
>
> > On Jul 6, 9:34 am, Ed Prochak <edproc...@gmail.com> wrote:
> >> On Jul 6, 4:39 am, speedplane <michael.san...@gmail.com> wrote:
> >> > On Jul 5, 11:58 pm, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
>
> > Message passing protocols can very easily have deadlocks and race
> > conditions. I have to deal with them all the time. One simple type of
> > message is sending a signal to another thread/application. If the
> > protocol is complex and the threads/apps are sending signals to each
> > other all the time, then you have to be prepared to handle many
> > different types of ordering between the two threads.
>
> Are you talking about synchronous (e.g. Unix signals) or asynchronous
> (queued) messages?
Well I certainly was thinking queued messages.
>
> > < Passing messages have no need to "suffer from deadlocks
> > < and race conditions" in a well designed interface
>
> > I think the key to your statement is "well designed interface".
> > Designing a good interface for a complex system is by no means easy.
> > In fact it may be one of the hardest parts of the entire project.
>
> And it should a hard part, as a lot of other things should be easy when
> the interface is done right.
And the issue of being "done well" is to use the message passing
features of the OS. Even small micro kernals have that feature
usually. Why reinvent such fundamental functionality?
>
> > Transactions are commonly used in databases to do processing on the
> > database atomically. There are a couple steps to a transaction in a
> > database:
> > 1) the hardware and/or software creates a small copy of the database
> > which it is going to modify
copy the whole DB? in hardware? what CPU are you using??
> > 2) It then does all of the processing on that mini-database
So how did the database suddenly become smaller?
> > 3) Once its done it checks to see if any other transaction modified
> > the memory in that mini-database
and how does it do that without some locking mechanism?
> > 4.a) If no one modified the original memory, then it commits its work
> > and the transaction completes.
> > 4.b) If another transaction modified that memory then it discards its
> > work and depending on the implementation either goes back to 1, or
> > returns some error.
The other solution is to commit if the user commands it. If there is
another transaction, it is working on its own copy of the data, so no
need to not write out the changes.
What you describe is one solution to transactions and deadlocking.
Oracle for example calls it Multiversioning. (Well to be fair, theirs
copies the unchanged data, allows the writes to happen, and discards
the copy of the old data on commit.)
>
> > The main advantage to transactions is that they are really easy to
> > program and its virtually impossible to deadlock them or cause race
> > conditions.
You silly boy. Even the holy Oracle DBMS can get these errors. Race
conditions are easy:
task A: update tableX set xcounter=xcounter + 1;
task B: update tableX set xcounter=xcounter + 1;
task A: commit;
task B: commit;
is the net effect an increase of 2 or 1?
locks are harder but still possible in such a transaction design.
> > The main disadvantage is that they are very hard to implement in non-
> > database systems and will probably require specialized hardware.
I do not know what special hardware would be needed. Oracle and other
DBMS products using this approach seem to run just fine on currrent
hardware. What opcode instruction would you want to support this,
speedplane?
Reply by speedplane●July 9, 20072007-07-09
On Jul 9, 4:50 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:
> Innews:1183754037.357307.236670@k79g2000hse.googlegroups.com
> timestamped Fri, 06 Jul 2007 13:33:57 -0700, speedplane
> <michael.san...@gmail.com> posted:
> "On Jul 6, 9:34 am, Ed Prochak <edproc...@gmail.com> wrote:
> > On Jul 6, 4:39 am, speedplane <michael.san...@gmail.com> wrote:
> >
> > > On Jul 5, 11:58 pm, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
> [..]
>
> Transactions are commonly used in databases to do processing on the
> database atomically. There are a couple steps to a transaction in a
> database:
> 1) the hardware and/or software creates a small copy of the database
> which it is going to modify
> 2) It then does all of the processing on that mini-database
> 3) Once its done it checks to see if any other transaction modified
> the memory in that mini-database
> 4.a) If no one modified the original memory, then it commits its work
> and the transaction completes.
> 4.b) If another transaction modified that memory then it discards its
> work and depending on the implementation either goes back to 1, or
> returns some error.
>
> [..]
> The main disadvantage is that they are very hard to implement in non-
> database systems and will probably require specialized hardware.
>
> As I said, this is still pretty far off. But the work is pretty
> interesting and may one day replace threads/mutex/semaphores.
>
> For further reading there is a java-like language that supports
> transactions:http://www.google.com/search?q=atomos+transactional
> "
>
> Do I misunderstand how transactions differ from cache coherence
> protocols for distributed systems without databases?
>
> "[..]
>
> The main advantage to transactions is that they are really easy to
> program and its virtually impossible to deadlock them or cause race
> conditions.
> [..]
>
> [..]"
>
> What is 4.b) described as?
>
> Regards,
> Colin Paul Gloster
Indeed transactions and some types of cache coherence protocols start
to look very similar. The main difference is in the step 4.b. That
step is typically called "rollback". The main difference between
these systems and current threading systems is that this transaction
interface is exposed to the programmer. They can use these transaction
primitives to parallelize their code. With cache-coherence everything
is hidden from the programmer which makes it very hard for the
hardware developer to find ways to parallelize their code.
Reply by Colin Paul Gloster●July 9, 20072007-07-09
In news:1183754037.357307.236670@k79g2000hse.googlegroups.com
timestamped Fri, 06 Jul 2007 13:33:57 -0700, speedplane
<michael.sander@gmail.com> posted:
"On Jul 6, 9:34 am, Ed Prochak <edproc...@gmail.com> wrote:
> On Jul 6, 4:39 am, speedplane <michael.san...@gmail.com> wrote:
>
> > On Jul 5, 11:58 pm, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
[..]
Transactions are commonly used in databases to do processing on the
database atomically. There are a couple steps to a transaction in a
database:
1) the hardware and/or software creates a small copy of the database
which it is going to modify
2) It then does all of the processing on that mini-database
3) Once its done it checks to see if any other transaction modified
the memory in that mini-database
4.a) If no one modified the original memory, then it commits its work
and the transaction completes.
4.b) If another transaction modified that memory then it discards its
work and depending on the implementation either goes back to 1, or
returns some error.
[..]
The main disadvantage is that they are very hard to implement in non-
database systems and will probably require specialized hardware.
As I said, this is still pretty far off. But the work is pretty
interesting and may one day replace threads/mutex/semaphores.
For further reading there is a java-like language that supports
transactions: http://www.google.com/search?q=atomos+transactional
"
Do I misunderstand how transactions differ from cache coherence
protocols for distributed systems without databases?
"[..]
The main advantage to transactions is that they are really easy to
program and its virtually impossible to deadlock them or cause race
conditions.
[..]
[..]"
What is 4.b) described as?
Regards,
Colin Paul Gloster
Reply by Boudewijn Dijkstra●July 9, 20072007-07-09
Op Fri, 06 Jul 2007 22:33:57 +0200 schreef speedplane
<michael.sander@gmail.com>:
> On Jul 6, 9:34 am, Ed Prochak <edproc...@gmail.com> wrote:
>> On Jul 6, 4:39 am, speedplane <michael.san...@gmail.com> wrote:
>> > On Jul 5, 11:58 pm, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
>>
> Message passing protocols can very easily have deadlocks and race
> conditions. I have to deal with them all the time. One simple type of
> message is sending a signal to another thread/application. If the
> protocol is complex and the threads/apps are sending signals to each
> other all the time, then you have to be prepared to handle many
> different types of ordering between the two threads.
Are you talking about synchronous (e.g. Unix signals) or asynchronous
(queued) messages?
> < Passing messages have no need to "suffer from deadlocks
> < and race conditions" in a well designed interface
>
> I think the key to your statement is "well designed interface".
> Designing a good interface for a complex system is by no means easy.
> In fact it may be one of the hardest parts of the entire project.
And it should a hard part, as a lot of other things should be easy when
the interface is done right.
> Transactions are commonly used in databases to do processing on the
> database atomically. There are a couple steps to a transaction in a
> database:
> 1) the hardware and/or software creates a small copy of the database
> which it is going to modify
> 2) It then does all of the processing on that mini-database
> 3) Once its done it checks to see if any other transaction modified
> the memory in that mini-database
> 4.a) If no one modified the original memory, then it commits its work
> and the transaction completes.
> 4.b) If another transaction modified that memory then it discards its
> work and depending on the implementation either goes back to 1, or
> returns some error.
>
> The main advantage to transactions is that they are really easy to
> program and its virtually impossible to deadlock them or cause race
> conditions.
> The main disadvantage is that they are very hard to implement in non-
> database systems and will probably require specialized hardware.
This description of transactions looks a lot like lock-free data
exchange. This also involves read-copy-update, but no rollback.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
Reply by ●July 7, 20072007-07-07
While this thread has been mostly about semantics, I would like to
comment on some points in the original question.
On Thu, 05 Jul 2007 12:42:33 +0200, "Boudewijn Dijkstra"
<boudewijn@indes.com> wrote:
>Op Mon, 02 Jul 2007 07:41:57 +0200 schreef ssubbarayan <ssubba@gmail.com>:
>> Most of us involved with RTOS projects in embedded systems need to
>> encounter at one point or other problems pertaining to real time
>> situations:
>> 1)DeadLocks
>
>No. Only possible in the classic and error-prone concept of 'shared
>resources'.
>
>> 2)Racing conditions
>
>No. Only possible in the classic and error-prone concept of 'non-exclusive
>ownership of data'.
As you have a clear view who owns a particular data (i.e. is allowed
to modify it), there should not be a great problem.
>> 3)Problems related to re-entrancy.
>
>No. Only possible in the classic and error-prone concept of 'non-readonly
>data that belongs to all processes'.
This was a major issue with FORTRAN and COBOL and with some stupid
C-library functions, but in general, in most stack based languages,
this should not be an issue, unless you really do some really stupid
things.
>> 4)Problems related with priority setting
>Never heard of this.
With any sensible division of labour between tasks, the priority
setting should be obvious.
>> What are the general debugging techniques used to uncover problems
>> related to above mentioned?
>
>If you didn't find these problems earlier, then the problem lies in the
>design phase.
Absolutely.
If you know that there are going to be problems debugging your
program, you should really spend more time in the design phase.
Even then, you should plan how to debug the system, e.g. by placing
some critical information into a static location so that any debugger
can find it.
BTW, the first time I heard about "priority inversion" was with the
Mars Rover story. However, I had been working with realtime
multitasking systems for more than a decade without that kind of
problems.
Paul
Reply by speedplane●July 6, 20072007-07-06
On Jul 6, 9:34 am, Ed Prochak <edproc...@gmail.com> wrote:
> On Jul 6, 4:39 am, speedplane <michael.san...@gmail.com> wrote:
>
> > On Jul 5, 11:58 pm, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
>
> > []
> > > Perhaps a better term in lieu of my 'to share' is 'to share directly'. A
> > > task can use a resource without knowing or caring how many others are
> > > using it, and therefore without the task knowing whether it is 'sharing'
> > > the resource.
>
> > There are three ways to threads/applications can share data. Messages
> > (like you mention), shared memory (which you forbid), and transactions
> > (only really exist in databases). Both messages and shared memory can
> > easily suffer from deadlocks and race conditions... although shared
> > memory makes it easier to screw up. Transactions are the way of the
> > future... unfortunately they are the distant future.-
>
> Shared memory may be a special case in that there may be some
> different understandings of what we all mean. In many cases however I
> disagree that it will
>
> > easily suffer from deadlocks and race conditions... although shared
> > memory makes it easier to screw up.
>
> the variations
> 1. A common memory pool, such as the heap used in C programming (via
> malloc() calls)
> 2. A common memory area at a fixed address and used by multiple
> applications
> a. with a simple interface (e.g. a circular buffer between 1
> producer and 1 consumer)
> b. with a complex interface (e.g. a buffer between multiple
> producers and consumers)
> 3. A memory segment shared between different CPUs (dual ported RAM or
> addressable RAM on a common backplane bus)
>
> 1. since there is a common monitor routine (i.e., malloc), there are
> no deadlocks and race conditions. They are handled in malloc()
>
> 2. a. there are simple algorithms for circular buffers. This is easy
> to do.
> 2. b. Here, you need to define a protocol. yes that may be subject to
> failures if not designed carefully. I think this is the case you are
> thinking about.
>
> 3. this is similar and a little more complex than case 2.b and may
> even require hardware assistance. But just needs careful design.
>
> Passing messages have no need to "suffer from deadlocks and race
> conditions" in a well designed interface. Message passing can be
> centralized (most OSs support some method) so the applications do not
> deal with any locking. Then above the message passing, you just build
> a application specific protocol. (for example, do all messages sent to
> a given application get a reply sent back?) Such message passing
> systems are little different than using IP (Internet Protocol).
>
> So where are your future transactional interfaces? in the OS or the
> application layer? Who builds them? Presumably they are more complex
> than a common memory library, so what makes them more reliable?
>
> Are they more reliable just because you are not involved in using or
> implementing them?
> sorry, I could not resist a little poke at you. 8^)
>
> Ed prochak
Message passing protocols can very easily have deadlocks and race
conditions. I have to deal with them all the time. One simple type of
message is sending a signal to another thread/application. If the
protocol is complex and the threads/apps are sending signals to each
other all the time, then you have to be prepared to handle many
different types of ordering between the two threads.
< Passing messages have no need to "suffer from deadlocks
< and race conditions" in a well designed interface
I think the key to your statement is "well designed interface".
Designing a good interface for a complex system is by no means easy.
In fact it may be one of the hardest parts of the entire project.
Transactions are commonly used in databases to do processing on the
database atomically. There are a couple steps to a transaction in a
database:
1) the hardware and/or software creates a small copy of the database
which it is going to modify
2) It then does all of the processing on that mini-database
3) Once its done it checks to see if any other transaction modified
the memory in that mini-database
4.a) If no one modified the original memory, then it commits its work
and the transaction completes.
4.b) If another transaction modified that memory then it discards its
work and depending on the implementation either goes back to 1, or
returns some error.
The main advantage to transactions is that they are really easy to
program and its virtually impossible to deadlock them or cause race
conditions.
The main disadvantage is that they are very hard to implement in non-
database systems and will probably require specialized hardware.
As I said, this is still pretty far off. But the work is pretty
interesting and may one day replace threads/mutex/semaphores.
For further reading there is a java-like language that supports
transactions: http://www.google.com/search?q=atomos+transactional
Reply by Ed Prochak●July 6, 20072007-07-06
On Jul 6, 4:39 am, speedplane <michael.san...@gmail.com> wrote:
> On Jul 5, 11:58 pm, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
>
>
> []
> > Perhaps a better term in lieu of my 'to share' is 'to share directly'. A
> > task can use a resource without knowing or caring how many others are
> > using it, and therefore without the task knowing whether it is 'sharing'
> > the resource.
>
> There are three ways to threads/applications can share data. Messages
> (like you mention), shared memory (which you forbid), and transactions
> (only really exist in databases). Both messages and shared memory can
> easily suffer from deadlocks and race conditions... although shared
> memory makes it easier to screw up. Transactions are the way of the
> future... unfortunately they are the distant future.-
Shared memory may be a special case in that there may be some
different understandings of what we all mean. In many cases however I
disagree that it will
> easily suffer from deadlocks and race conditions... although shared
> memory makes it easier to screw up.
the variations
1. A common memory pool, such as the heap used in C programming (via
malloc() calls)
2. A common memory area at a fixed address and used by multiple
applications
a. with a simple interface (e.g. a circular buffer between 1
producer and 1 consumer)
b. with a complex interface (e.g. a buffer between multiple
producers and consumers)
3. A memory segment shared between different CPUs (dual ported RAM or
addressable RAM on a common backplane bus)
1. since there is a common monitor routine (i.e., malloc), there are
no deadlocks and race conditions. They are handled in malloc()
2. a. there are simple algorithms for circular buffers. This is easy
to do.
2. b. Here, you need to define a protocol. yes that may be subject to
failures if not designed carefully. I think this is the case you are
thinking about.
3. this is similar and a little more complex than case 2.b and may
even require hardware assistance. But just needs careful design.
Passing messages have no need to "suffer from deadlocks and race
conditions" in a well designed interface. Message passing can be
centralized (most OSs support some method) so the applications do not
deal with any locking. Then above the message passing, you just build
a application specific protocol. (for example, do all messages sent to
a given application get a reply sent back?) Such message passing
systems are little different than using IP (Internet Protocol).
So where are your future transactional interfaces? in the OS or the
application layer? Who builds them? Presumably they are more complex
than a common memory library, so what makes them more reliable?
Are they more reliable just because you are not involved in using or
implementing them?
sorry, I could not resist a little poke at you. 8^)
Ed prochak