[9fans] Got thread experience?

[9fans] Got thread experience?

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So, those with experience with threading implementations on weird
real-time or embedded operating systems:

Have you ever ran into a thread implementation where two threads
could *not* directly access each other's .bss (or equiv)/heap?

i.e. have you ever encountered a scenario where sibling threads
actually had completely separate sets of page tables?

D

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHIQElyWX0NBMJYAcRAvsnAJ99vVKCXnMRSlRCuB2Ze8w27bo68ACcDxq5
5mbh3khmpgLvHYKUI9NzFPQ=
=4/Qy
-----END PGP SIGNATURE-----

Re: [9fans] Got thread experience?

[erik quanstrom]

> So, those with experience with threading implementations on weird
> real-time or embedded operating systems:
> 
> Have you ever ran into a thread implementation where two threads
> could *not* directly access each other's .bss (or equiv)/heap?
> 
> i.e. have you ever encountered a scenario where sibling threads
> actually had completely separate sets of page tables?

under plan 9, don't we call those processes?

that doesn't sound like any imbedded environment i've worked in.
it's getting mighty fancy to have one set of pagetables. ;-)

- erik

Re: [9fans] Got thread experience?

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> under plan 9, don't we call those processes?
> 
> that doesn't sound like any imbedded environment i've worked in.
> it's getting mighty fancy to have one set of pagetables. ;-)
> 

You're cute, but I'm trying to be serious.
It's an odd question, I know.

D

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHIQREyWX0NBMJYAcRAs3HAJ9k6acxdN/9THLrszp1lLXY+xDk7ACgkuTJ
0dVCU4aacvfHQ+y3koC2Y5U=
=nrUZ
-----END PGP SIGNATURE-----

Re: [9fans] Got thread experience?

[erik quanstrom]

>> under plan 9, don't we call those processes?
>> 
>> that doesn't sound like any imbedded environment i've worked in.
>> it's getting mighty fancy to have one set of pagetables. ;-)
>> 
> 
> You're cute, but I'm trying to be serious.
> It's an odd question, I know.

well although i was being funny, the point was serious.
what you describe -- loci of execution with seperate address
spaces (page tables) are usually thought of as processes
in unix-like environments.  i would suspect that csp
tools are available like send and recv?

- erik

Re: [9fans] Got thread experience?

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> well although i was being funny, the point was serious.
> what you describe -- loci of execution with seperate address
> spaces (page tables) are usually thought of as processes
> in unix-like environments.  i would suspect that csp
> tools are available like send and recv?
> 

Ya, and I would normally consider them processes. That's
why I mentioned real-time or embedded operating systems.
I just want to make sure I'm not missing anything :-)

D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHIQb9yWX0NBMJYAcRArGFAJ9tch8nlS4ECXFzTjC7s5R8/DpCKgCfWoDM
w+q0cOtT8hcy9Ev6o9u4k/k=
=FpXy
-----END PGP SIGNATURE-----

Re: [9fans] Got thread experience?

[erik quanstrom]

> Ya, and I would normally consider them processes. That's
> why I mentioned real-time or embedded operating systems.
> I just want to make sure I'm not missing anything :-)
> 
> D

are they independently or cooperatively scheduled?

- erik

Re: [9fans] Got thread experience?

[Pietro Gagliardi]

On Oct 25, 2007, at 5:06 PM, erik quanstrom wrote:

>>> under plan 9, don't we call those processes?
>>>
>>> that doesn't sound like any imbedded environment i've worked in.
>>> it's getting mighty fancy to have one set of pagetables. ;-)
>>>
>>
>> You're cute, but I'm trying to be serious.
>> It's an odd question, I know.
>
> well although i was being funny, the point was serious.
> what you describe -- loci of execution with seperate address
> spaces (page tables) are usually thought of as processes
> in unix-like environments.  i would suspect that csp
> tools are available like send and recv?
>
> - erik
>

I have a book teaching development of an OS via a non-UNIX variant  
that also applies to the share-a-page-table rule. I doubt there is  
any with broken rules - except ones with no idea of threads, in which  
there would only be processes. Oh well, too many specifics for every  
generalization.

Re: [9fans] Got thread experience?

[Pietro Gagliardi]

/* there are threads in plan 9 */
#include <u.h>
#include <libc.h>
#include <thread.h>

int killme = 0, i = 0, x = 0;

void thread_task(void *data)
{
    i++;
    if (i > 2000) {
        x++;
        killme = x > 200;
    }
}

/* threadmain() instead of main() - requires argc, argv */
void threadmain(int argc, char *argv[]) /* must use *argv[] - not  
**argv or argv[][] */
{
     int tid;

     tid = threadcreate(thread_task, 0, 2048); /* (function,  
argument, stack size) */
     if (tid < 0)
         sysfatal("could not create thread");
     while (!killme) {
         print(1, "waiting\n");
         sleep(2000); /* wait two seconds */
     }
     threadexitsall(0); /* use instead of exits() - with all suffix,  
terminates all threads */
}

On Oct 25, 2007, at 4:51 PM, erik quanstrom wrote:

>> So, those with experience with threading implementations on weird
>> real-time or embedded operating systems:
>>
>> Have you ever ran into a thread implementation where two threads
>> could *not* directly access each other's .bss (or equiv)/heap?
>>
>> i.e. have you ever encountered a scenario where sibling threads
>> actually had completely separate sets of page tables?
>
> under plan 9, don't we call those processes?
>
> that doesn't sound like any imbedded environment i've worked in.
> it's getting mighty fancy to have one set of pagetables. ;-)
>
> - erik
>

Re: [9fans] Got thread experience?

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pietro Gagliardi wrote:
> /* there are threads in plan 9 */
>

Ok, let me clarify because I think people are very confused: and that's
understandable given the weirdness of the question.

I'm looking for any corner case operating system that (due to scheduling
and other semantics) sees threads as not having the usual set of shared
memory segments. I haven't found any but I'm interested in verifying
because of a project at work.

No, this doesn't make sense. Yes, it *should* be seen as a "process".
But, I'm being extremely pedantic.

D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHIQa0yWX0NBMJYAcRApmlAJ0YiVkfsDJVvviPXMJ5nOTTsxOPeACeJGBC
RwBJSz1dV800DXm4txiTwFw=
=L0u2
-----END PGP SIGNATURE-----

Re: [9fans] Got thread experience?

[Charles Forsyth]

> Have you ever ran into a thread implementation where two threads
> could *not* directly access each other's .bss (or equiv)/heap?
> i.e. have you ever encountered a scenario where sibling threads
> actually had completely separate sets of page tables?

yes. erlang processes do not share memory (and it is used in embedded real-time applications).

Re: [9fans] Got thread experience?

[roger peppe]

threads on inmos transputers didn't share memory. the threads
were scheduled by the processor itself (zero context-switch time,
which was nice), but could just as easily
be on separate processors - the code couldn't tell (apart from
the fact that there were only four channels out of each processor)

i don't *think* you could pass shared references around, but
it was a long time ago.

Re: [9fans] Got thread experience?

[Andy Newman]

roger peppe wrote:
> threads on inmos transputers didn't share memory. the threads
> were scheduled by the processor itself (zero context-switch time,
> which was nice), but could just as easily be on separate processors

occam processes (aka threads) can share state but the language
enforces read-only access (unless you turn off that checking
which you often needed to given limitations in its implementation).
State sharing, of course, doesn't work when processes are mapped
to different processors (although the machine I used to use had a
large chunk of memory shared between the CPUs where we kept data
we didn't want to move around).

The transputer's context switch did have a small cost but it was
fast for its time.  Three registers written to the on-chip RAM.
Given the nature of occam, and the transputer being an engine
for running occam, efficient support for lots of processes is
a must.  These days people seem to be getting all excited about
it again.

> i don't *think* you could pass shared references around, but
> it was a long time ago.

It was possible.  But like yourself its been a long time since
I did all this (twenty years) and the details are sketchy but
we definitely passed addresses down channels and did shared
accesses (no pesky MMU to get in the way :)

Re: [9fans] Got thread experience?

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks, guys. I appreciate the posts.

D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHIggsyWX0NBMJYAcRAjCYAJ4yzGB0+8Q/RF2SiKH4AG9V6FSvlQCeKgYk
4Ntfu5ZsJWTBs8BX7BrErq0=
=2SqU
-----END PGP SIGNATURE-----

Re: [9fans] Got thread experience?

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

On 10/25/07, Charles Forsyth <forsyth@terzarima.net> wrote:
>
> > Have you ever ran into a thread implementation where two threads
> > could *not* directly access each other's .bss (or equiv)/heap?
> > i.e. have you ever encountered a scenario where sibling threads
> > actually had completely separate sets of page tables?
>
> yes. erlang processes do not share memory (and it is used in embedded
> real-time applications).
>
>
> Aren't those processes though and not threads?

[-- Attachment #2: Type: text/html, Size: 923 bytes --]

Re: [9fans] Got thread experience?

[Sape Mullender]

> So, those with experience with threading implementations on weird
> real-time or embedded operating systems:
> 
> Have you ever ran into a thread implementation where two threads
> could *not* directly access each other's .bss (or equiv)/heap?
> 
> i.e. have you ever encountered a scenario where sibling threads
> actually had completely separate sets of page tables?

Plan 9 distinguishes between threads and procs.  Procs are Plan 9
processes and can therefore have address spaces different from other
processes.  Usually, in threaded applications, the proc address
spaces only differ in the stack.

However, we have real-time embedded applications where some procs
map in memory segments that can be used to access certain peripherals.
In such applications procs do have different address spaces.  But they
are only somewhat different, certainly not as different as indicated
above.

	sape