Skip site navigation (1)Skip section navigation (2)
Date:      01 Nov 1999 20:28:26 +0000
From:      Randell Jesup <rjesup@wgate.com>
To:        freebsd-arch@freebsd.org
Subject:   Re: Threads goals version III
Message-ID:  <ybu1zaagdn9.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
In-Reply-To: Jake Burkholder's message of "Mon, 01 Nov 1999 15:17:42 -0800"
References:  <19991101231743.F30501FD7@io.yi.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Jake Burkholder <jake@checker.org> writes:
>int global;  /* all threads can access this */
>
>main() {
>	thread t1;
>	int mainvar;
>	
>	/* this could also be mmaped or stack based storage */
>	t.stack = malloc(some memory);

	What's this for?  Wouldn't each new thread have it's own
stack space allocated by the thread library/kernel?  (Perhaps
according to size requests in new_thread, or just an automatically
grown segment of the process (not thread) VM space.)  Note: I haven't
looked at Unix thread library details.

>	new_thread(&t1, foo, 1, &mainvar);

>foo(int ac, ...) {	

>	/* t1 now has access to mainvar through p */

>
>The WHOLE address space is shared.  You can pass around
>pointers to stack based storage, but a new thread executes
>a new start_routine, so it can't access variables from the
>scope in which new_thread was called, only what get passed
>into start_routine.

	Also, inter-thread IPC and implicit shared structures might
include pointers to stack variables, such as for a synchronous
request from another thread for data to be put into a buffer on the
stack, such as: (pseudo-code)

void
bar(unsigned char *encoded_data, unsigned long encoded_data_len)
{
 unsigned char buffer[1000];
 msg->out_buffer = &buffer[0];
 msg->out_buflen = sizeof(buffer);
 msg->in_buffer = encoded_data;
 msg->in_buflen = encoded_data_len;
 msg->command = DECODE_DATA;

 // do_message is synchronous, sends a message and waits for a reply
 do_message(decode_thread,msg);

 // do something with buffer data
}


	What synchronization (semaphores, etc) and inter-thread messaging
mechanisms are we thinking of?

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
rjesup@wgate.com





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybu1zaagdn9.fsf>