Passing messages between programs - nonstandard way

[partytime4321]

Hi all,

I have a bit of an issue, I need direct access to parallel ports, on a school owned computer which probably wont let me install any drivers.

So, the school expects us to use a very stupid language called Turing. (its forced, and you have no idea how much I hate it.)

For this assignment, my teacher said we could write it in another language if we can make it work with the parallel port (to control the breadboard we will be working on). IT installed the parallel port driver for Turing (after much difficulty), so I was hoping to somehow communicate with a Turing program via C++, so I can do the graphics and logic in C++ and then just have the Turing program control the port itself. The problem is, Turing is DEAD. It doesn't support win32 message passing and the network module causes the entire environment to crash.

Unless anyone knows an easy way to write to a parallel port in c/c++ (just write, no read), the only way I can think to pass a message to the Turing program would be through a file on the disk.

The problem is, there needs to be communication throughout the entire execution, not just at the start. Latency would have to be around 0.5 seconds, so not super intensive, and there would be a message every few seconds. Ideally, the Turing program would be able to send stuff back through another file, but this may not be needed.

My question: how could I handle this so that there is little to no risk of either program crashing? What happens if one program reads a file, at the same time another program is writing to it? I have never done something like this before, so I have no idea how the programs might react, or what other implications it could have.

Thanks very much,
Ryan

[SamuelAdams]

2 programs reading the same file isnt a problem, writing at the same time is another issue.

I would have the C++ program write to the file, you might have the first line be the control code, so the first time you write to it, the first line would be 0001, the second time 0002. The turing program would read the first line and you would know if it's already been processed.

If you need to pass something to the C++ program, use a different file. So if your turing program is reading the file, you might make a second file, like a lock file, if anything is in it, then the C++ program would wait 5-10 seconds and check it again before changing it's output file.

[partytime4321]

I like the idea of the revision number on the first line, that's a good idea... I also considered locking the file when being written, I can do that for the c program but I don't know about the Turing one (sigh).

The only problem is that the programs have to look roughly synchronized, so they would have to look at least every second, but preferably every half second... Do you think that would be possible?

Failing being able to speed it up, I might be able to do it based on odd vs even seconds, if I can accurately get time in Turing, and then apply some sort of smoothing to make them seem synced.

Thanks a lot,
Ryan

[tvrameshmc]

In my view better to use one file for one communication.

Let us consider two programs can initialize that 1 to 10000 is the range of files.
First writer writes first communication in 1.dat file for next communication he writes in 2.data like that incrementally he uses 10000.dat, after completion of 10000 again start from 1.dat like that.

In Readers perspective reader can also initialize same range 1 to 10000.
First time reader will read data from 1.dat file and delete it next 2.dat and so on after 10000.dat again start from 1.dat.

In reading time program must wait if particular number file not present .

[coder777]

I'd suggest implementing a ring (or circular) buffer:

http://en.wikipedia.org/wiki/Circular_buffer

I suggest: the first (unsigned) byte is the write index and the second is the read index.

-> after finish writing increase the write index
-> before reading check whether read/write index is different -> read until read/write index is the same (of course the read index is increased after each successful read too)

using an (unsigned) byte as index means that you can write 256 times (without any read) until you get in trouble. That's supposed to suffice. Plus no need to check for limits (255 + 1 = 0)

No need for synchronizing

the communication is rather fast since it's likely that the file remains in memory

[partytime4321]

Thanks for all the great ideas guys!

I got it working, with the exception of multi threading the c++ program (the way the file exchanges work there would have to be multiple threads, the way I see it, as there's a lot of waiting for ones turn to read or write (perhaps I can shorten it)

If anyone is interested now or in the future:

Currently what I did is I made 2 files, one for turing -> c++, the other for c++ -> turing. On odd numbered seconds based on the system clock, the programs each check if they are waiting to send a message, and if so they can write one message to the other programs file (using the idea of the first line being the number of the message). Programs then stall inefficiently until the second rolls over (basically they just constantly check the clock, and exit as soon as its different from the initial second - I don't know if there is a more efficient way but I would assume so) then when the second rolls over, check and find that it's even, so both programs open their corresponding files, read the first line, check if it is the same number as before (if it is just close it, and wait) otherwise read the new message and update the input counter.

There's a 2 second RTT, which might be alright for the purpose, but if it needs to be faster I can probably do it using one file per message as said by tvram, and the file name as the counter (my thought is if I can just check if it exists first before opening, it can be done faster because it won't matter if there is a simultanious check and write.

Coder, what do you mean when you say the file can remain in ram? Wouldn't the process have to check the disk every time, because it doesn't know if it was modified by the other process?

Thanks very much everyone!
Ryan

[coder777]

what do you mean when you say the file can remain in ram? Wouldn't the process have to check the disk every time, because it doesn't know if it was modified by the other process?

Accessing the disk is indeed slow. Especially open since the system has to find the file on the disk. Once the file is open the access is buffered. Therefore chances are great that with one file the read/write operation take place within ram and not on disk.

I know that the ring buffer concept is not the easiest to understand, but in this case I'd say that it'd be the fastest