OSDev.org

Avarok wrote:Heh...

Threads are supposed to be parallel transformations on a data set, however that would require that data not be shared at all between them. Then you have processes. Threads are *supposed* to share the data they transform.

With that understood, often the data needs to be in a certain state for the a given thread to continue execution. This will typically rely on the output of another thread or external event. The thread *could* just infinitely loop until the result came, or we can have it give up it's execution time to something else. The desireable thing often appears to be to cede it's time to the thread it's waiting for.

So yeah, again, the difference between threads and processes is that threads aren't isolated from one another in memory, and so can share memory without any additional abstraction. This is better in all cases except when one thread cannot trust another thread (the bad thread could change my stack, or overwrite my code - )

You could potentially (though I don't see why) even let the threads wander between "processes".

What, exactly, are synchronous cross-thread calls? I thought the point of a thread was that it ran its own instruction stream, and therefore couldn't "called" into or out of.

But this stuff sounds interesting and right up my alley (I'm into portal-based IPC.), so please do explain.

obj->func(param);

semaphore s;
param parameters;
retval returnValue;

thread1()
{
  // do stuff
  parameters = params_to_call;
  s.wait();
  // <return value is in returnValue.>
}

thread2()
{
  // do stuff
  while(1) {
    // do more stuff
    if(s.test())
    {
      returnValue = performFunc(parameters);
      s.signal();
    }
  }
}

JamesM wrote:

You could potentially (though I don't see why) even let the threads wander between "processes".

How, exactly? when you put the thread in a new address space it won't be able to access it's own code... :S

JamesM wrote:

You could potentially (though I don't see why) even let the threads wander between "processes".

How, exactly? when you put the thread in a new address space it won't be able to access it's own code... :S

JamesM wrote:You also seem to be blurring the line between threads and processes quite deliberately. Why would you want to have dozens of threads in one process with multiple entry and code segments?

JamesM wrote:Not only are you reducing the amount of address space available to each thread for personal storage, but you are just asking for memory corruption. Mutexes can only go so far- having dozens of threads concurrently accessing shared memory will either lead to corruption (with badly programmed code) or starvation (deadlock is just blatantly around the corner).

JamesM wrote:The difference between threads and processes is threads share memory. If you need dozens of lightweight processes all sharing global memory, perhaps it is time to rethink your design strategy!!

What, exactly, are synchronous cross-thread calls? I thought the point of a thread was that it ran its own instruction stream, and therefore couldn't "called" into or out of.

But this stuff sounds interesting and right up my alley (I'm into portal-based IPC.), so please do explain.

<in thread 2>
while(1) {
  waitFor(thread[7], 3);
  doSomething(bob);
  wait();
}

<in thread 7>
bob = 14;
signal(3);
waitFor(thread[2], 1);
return bob;

I was referring to any interprocess-communication system ... [snip] ... It is essentially a glorified message-passing system, but the calling semantics are much nicer: [snip] Some stub code inside that function can make it be called by any process or (later) thread.

Wow... that's a tough one. There are probably a million ways. The most obvious to me is to pause the thread, modify it's EIP from the stack, copy the code segment over somewhere and resume.

Well, threads are lighter weight than processes. Having one for each entry point can make sense, having them for event handling can make sense, or dedicating threads to different tasks that you want to do at the same time makes sense as long as you don't have to worry about security. 

That sounds most dangerous. I'll assume it's not. Perchance you can explain how though. I don't see it.

class C : RemoteProcedureCall
{
  RPC_DEFINE1(0, int, C, myMethod, int); // The 0 should just be any unique integer
public:
  C()
  {
     RPC_REGISTER(myMethod);
  }
  int myMethod(int param)
  {
     RPC_SYNC(myMethod, param);
     // Do stuff
     return 5;
  }
};

// Some code somewhere else
C *myC = new myC();
myC->myMethod(3); // This will be synchronous and remote.

#define RPC_DEFINE1(idx, returnValue, className, func, param) \
  const int __rpcconst__##func = idx; \
  static returnValue __rpccall__##func(className *obj, param p1) \
  { \
    return obj->func(p1); \
  }

#define RPC_REGISTER(func) \ 
processManager.getProcess()->registerRpcHandler(__rpcconst__##func, __rpccall__##func);

#define RPC_SYNC(func, param) \
  if (getpid() != targetPid) \
  { \
    return rpcSynchronous(__rpcconst__##func, (void*)param); \
  }

class RemoteProcedureCall
{
  RemoteProcedureCall()
  {
    targetPid = getpid(); // The process that created us becomes our "owner" or target.
  }

protected:
  int targetPid;

  template <BLAH LOTS OF TEMPLATE PARAMS>
  R rpcSynchronous(Obj, Func, ..........)
  {
 .....
  }
}

void func()
{
  RPC_SYNC(func);
}