hi,
For some purposes when sending ipc to other threads in my task space, I find the need to explicitly state a taskid problematic. This information is redundant, and redundancy _always_ leads to problems.
For me, the problem occurs when I move the l4linux server to a new task number, and another l4linux runs with my old number. All my threads get confused, and there is little I can do to help them (not without C&C at least, but that would still force me to use a taller task hierachy than I would like).
What I need is something like 'if partner.id.task==0 then partner.id.task=current.id.task' in the kernel, and I suppose I will make such a hack myself.
Is this what the rumoured 'lipc' feature in Pistachio is all about? Or is such a feature already present?
thanks, Jacob
[Jacob Gorm Hansen]
hi, For some purposes when sending ipc to other threads in my task space, I find the need to explicitly state a taskid problematic. This information is redundant, and redundancy _always_ leads to problems.
For me, the problem occurs when I move the l4linux server to a new task number, and another l4linux runs with my old number. All my threads get confused, and there is little I can do to help them (not without C&C at least, but that would still force me to use a taller task hierachy than I would like).
What I need is something like 'if partner.id.task==0 then partner.id.task=current.id.task' in the kernel, and I suppose I will make such a hack myself.
Is this what the rumoured 'lipc' feature in Pistachio is all about? Or is such a feature already present?
In Version 4 a thread can be addressed with two different ids: a local thread id which is only valid within the current address space, and a global id which is unique among all address spaces.
There is no such thing as a task number in version 4. You associate a thread with an address space by specifying another thread within that address space. As such, there is no direct connection between the thread id and the address space the thread lives in. This means that thread id 1 could reside in address space A, thread 2 reside in address space B, and threads 3 through 30.000 also reside in address space A. There is also no limit to the number of threads an address space can contain.
Thread ids are assigned to the threads when they are created (i.e., a user-level policy) and the API allows for arbitrary large holes in the thread id space. This enables the old pre-version-4 schemes to be emulated by a user-level policy. That is, one lets the X least significant bits designate the thread id within a task, and lets the remaining bits designate the task number (the address space the threads live in).
Now, to answer your question: if you migrate a thread, change the global thread ids in the process, and use global ids for accessing the threads, then, yes, you will still have some very confused threads. If you on the other hand ensure that the local ids are not changed on migration and use local ids for intra-space communication, then your system is likely to behave better.
The LIPC feature is certainly not rumoured (it's in the specs). Neither was it introduced to solve problems associated with migration (one can use local ids for normal IPC operations too). The reasons for introducing LIPC are purely performance related (intra address space IPC operations of ~20 cycles).
eSk
Jacob Gorm Hansen jg@ioi.dk writes:
For some purposes when sending ipc to other threads in my task space, I find the need to explicitly state a taskid problematic. This information is redundant, and redundancy _always_ leads to problems.
For me, the problem occurs when I move the l4linux server to a new task number, and another l4linux runs with my old number. All my threads get confused, and there is little I can do to help them (not without C&C at least, but that would still force me to use a taller task hierachy than I would like).
What I need is something like 'if partner.id.task==0 then partner.id.task=current.id.task' in the kernel, and I suppose I will make such a hack myself.
If you add such a hack to Fiasco, please send a patch and we will consider adding it as an optional experimental feature.
Cheers, Michael
On Thu, 2002-10-24 at 18:56, Michael Hohmuth wrote:
Jacob Gorm Hansen jg@ioi.dk writes:
If you add such a hack to Fiasco, please send a patch and we will consider adding it as an optional experimental feature.
OK I will. Its two lines I suppose. Sending it over the weekend.
I also have a small patch for your oskit support which I will send. It has to do with ensuring that the driver-thread is always the one signalled, which makes things easier for the user.
best, Jacob
l4-hackers@os.inf.tu-dresden.de