Re: race condition?

Tab,
  Expanding on your comments, here's the worst case conditions we need
to account for (let me know if I've forgotten any.) Again, I'm not much
of a software guy so let me know if I'm heading in the wrong direction.

1)  remote node sends a syscall home for processing at the same time the
home node sends a migration home command (or signal) to the remote node.
 The network packets pass each other in flight.

2)  The remote node sends a syscall home and the home node sends the
response but the remote node errors out and sends home an error
condition.  

(longer term)
3)  We have an SMP machine with a process that forked after it migrated,
so both processes share the same file descriptor.   Both processes send
syscalls home at the same time (one write and one read for example.).  
Home node sends a migration command at the same time.


A)  The home node has a queue for things it needs to send the remote
node.
B)  The remote node is the boss and if both nodes want to do something,
remote always wins.
C)  Acks are always send before anything, so both know who is talking
and who is listening."
D)  There's a response/ack for each communication.
E)  The structs have two more fields,  originating node
('home','remote'), and msg_num.


"I'm sending syscall X to you, and give me back the result",
"sending page X, then page Y, ..." ... 

becomes
remote: "Ok, I'm not currently processing a signal or command from the
home node. I'm gonna set a flag saying I'm doing the talking."
remote:  "Hey, home node,  I'm gonna send you a syscall."
home: "OK, go ahead, I have a signal in my queue I need to send you, but
you have priority, I'll try again later."
remote: "I got your request but ignored it since my flag is set. Here
comes my syscall. Let me know if you got it."
home: "Ok, I got it. Response will be next"
remote: "Awaiting response"
home: "Here's the response, page X, let me know if you got it ok."
remote:  "I have an error."
home:  "Ok, I'll resend."
remote: "I still have the error."
home:  "Ok. Nothing I can do to help you."
remote:  "I'm done with you, I'm returning an error code to the calling
function. and I'm clearing my flag."
...
home: "Hey remote, I want to send you a signal."
remote: "OK, I'll set a flag saying you're doing the talking."
home: "here's the signal <msg_num=12>."
remote: "Got it <and the msg_num is 12>. Any more?"
home: "Nope. I'm done."
remote: "OK, you're done, I'm clearing my flag."

Thoughts?

It's really verbose, but doing everything over one port is harder than
having two (or more) ports.

How do you put a process to sleep for event number X when the events are
all just tcp packets?

Matt



>>> Vincent Hanquez <tab-mTI/[email protected]> 05/15/06 9:09 AM >>>
On Mon, May 08, 2006 at 11:59:48AM -0600, Matt Dew wrote:
>  What are the thoughts on the condition where the remote node sends a
> syscall back to the home node and then receives a migrate home command
> before the syscall response?   Is this the same problem (out of
> sync-ness) that is causing the received -32 of 8 errors?
> 
> What is the best way to fix this?  
>  1) Put in some ack/nack commands to ensure both remote and deputy are
> in the same place?

it's actually going further than that. this kind of protocol is totally
asynced. However, everything expect sync stuff.

like "I'm sending syscall X to you, and give me back the result",
"sending page X, then page Y, ..." ... 

Most of this is protected by the fact that there's one connection per
task, but let say you want to tell the deputy that there's an error just
after receiving page X, you can't since the deputy is not expecting
data.

>  2) Open two ports. One for migration stuff and another for syscalls?

a command port and a data port would probably be better here than a
migration and syscall one. but I'd rather not favor that.
2 ports per process ...

>  3) Modify the functions to handle these cases?
>  4) Add a counter field to the structs for bookkeeping; so both remote
> and deputy know which response goes with which command and then merge
> the calling functions?

4 is probably the best here. You'll end up beeing able to put to sleep
process for event number X, instead of putting to sleep process until
there's data to read on the port.


However The ultimate move is to move the whole migration and remote
process handling in userspace. That's just crazy to be in kernel and
totally unneeded.  At the end it will provide something far more stable,
clean and hackable, where openMosix is a totally userspace thing (with
very small kernel module, that have actually almost nothing to do with
oM).

Cheers,
-- 
Vincent Hanquez


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
openMosix-devel mailing list
openMosix-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/openmosix-devel



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642