Re: Threads Design. A Win32 perspective.

2004-01-07 Thread Elizabeth Mattijsen
At 23:10 -0500 1/5/04, Gordon Henriksen wrote: Data corruption unacceptable? I disagree. It depends on the contract put forward by the language in question. Notably, Perl makes no such guarantees thus far, being as how it doesn't (any longer) run in a traditional threaded model. Successfully

Re: Threads Design. A Win32 perspective.

2004-01-07 Thread Dan Sugalski
At 23:10 -0500 1/5/04, Gordon Henriksen wrote: Data corruption unacceptable? I disagree. I get the feeling people just aren't reading what's been written, or aren't keeping it all straight. *User* and *program* data integrity is not our problem -- not only are we not guaranteeing that, I'd be

Re: Threads Design. A Win32 perspective.

2004-01-06 Thread Gordon Henriksen
On Sunday, January 4, 2004, at 03:17 , Jeff Clites wrote: On Jan 3, 2004, at 8:59 PM, Gordon Henriksen wrote: On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote: Transparent interlocking of VHLL fat structures performed automatically by the VM itself. No need for :shared or lock().

Re: Threads Design. A Win32 perspective.

2004-01-06 Thread Gordon Henriksen
On Sunday, January 4, 2004, at 01:43 , Dan Sugalski wrote: At 11:59 PM -0500 1/3/04, Gordon Henriksen wrote: On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote: Transparent interlocking of VHLL fat structures performed automatically by the VM itself. No need for :shared or lock().

RE: Threads Design. A Win32 perspective.

2004-01-06 Thread Garrett Goebel
Gordon Henriksen wrote: Dan Sugalski wrote: An interpreter *must* lock any shared data structure, including PMCs, when accessing them. Otherwise they may be in an inconsistent state when being accessed, which will lead to data corruption or process crashing, which is unacceptable.

Re: Threads Design. A Win32 perspective.

2004-01-05 Thread Dan Sugalski
At 4:03 PM -0800 1/4/04, Damien Neil wrote: It's my understanding that Parrot has chosen to take the path of using many mutable data structures at the VM level; unfortunately, this is pretty much incompatible with a fast or elegant threading model. Yep, generally true. The choice was made on

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Elizabeth Mattijsen
At 00:49 +0100 1/4/04, Leopold Toetsch wrote: Elizabeth Mattijsen [EMAIL PROTECTED] wrote: Indeed. But as soon as there is something special such as a datastructure external to Perl between threads (which happens automatically shared automatically, because Perl doesn't know about the

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Gordon Henriksen
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote: Transparent interlocking of VHLL fat structures performed automatically by the VM itself. No need for :shared or lock(). Completely specious, and repeatedly proven unwise. Shouldn't even be pursued. Atomic guarantees on collections

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Leopold Toetsch
Elizabeth Mattijsen [EMAIL PROTECTED] wrote: When you use an external library in Perl, such as e.g. libxml, you have Perl data-structures and libxml data-structures. The Perl data-structures contain pointers to the libxml data-structures. In comes the starting of an ithread and Perl clones

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Elizabeth Mattijsen
At 14:47 +0100 1/4/04, Leopold Toetsch wrote: Elizabeth Mattijsen [EMAIL PROTECTED] wrote: When you use an external library in Perl, such as e.g. libxml, you have Perl data-structures and libxml data-structures. The Perl data-structures contain pointers to the libxml data-structures. In

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Dan Sugalski
At 11:59 PM -0500 1/3/04, Gordon Henriksen wrote: On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote: Transparent interlocking of VHLL fat structures performed automatically by the VM itself. No need for :shared or lock(). Completely specious, and repeatedly proven unwise. Shouldn't

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Jeff Clites
On Jan 4, 2004, at 5:47 AM, Leopold Toetsch wrote: Elizabeth Mattijsen [EMAIL PROTECTED] wrote: When you use an external library in Perl, such as e.g. libxml, you have Perl data-structures and libxml data-structures. The Perl data-structures contain pointers to the libxml data-structures. In

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Jeff Clites
On Jan 3, 2004, at 8:59 PM, Gordon Henriksen wrote: On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote: Transparent interlocking of VHLL fat structures performed automatically by the VM itself. No need for :shared or lock(). Completely specious, and repeatedly proven unwise.

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Uri Guttman
DS == Dan Sugalski [EMAIL PROTECTED] writes: DS And don't forget the libraries that are picky about which thread calls DS into them -- there are some that require that the thread that created DS the handle for the library be the thread that calls into the library DS with that handle.

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Sam Vilain
On Sat, 03 Jan 2004 20:51, Luke Palmer wrote; Parrot is platform-independent, but that doesn't mean we can't take advantage of platform-specific instructions to make it faster on certain machines. Indeed, this is precisely what JIT is. But a lock on every PMC is still pretty heavy

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Dan Sugalski
At 3:17 PM -0500 1/4/04, Uri Guttman wrote: DS == Dan Sugalski [EMAIL PROTECTED] writes: DS And don't forget the libraries that are picky about which thread calls DS into them -- there are some that require that the thread that created DS the handle for the library be the thread that

Re: Threads Design. A Win32 perspective.

2004-01-04 Thread Damien Neil
On Sun, Jan 04, 2004 at 12:17:33PM -0800, Jeff Clites wrote: What are these standard techniques? The JVM spec does seem to guarantee that even in the absence of proper locking by user code, things won't go completely haywire, but I can't figure out how this is possible without actual

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Nigel Sandever
On Sat, 03 Jan 2004 01:48:07 -0500, [EMAIL PROTECTED] (Uri Guttman) wrote: ding! ding! ding! you just brought in a cpu specific instruction which is not guaranteed to be on any other arch. in fact many have such a beast but again, it is not accessible from c. you can't bring x86 centrism into

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Luke Palmer
Nigel Sandever writes: Maybe it would be possible (for me + others) to write the core of a win32 specific, threaded VM interpreter that would take parrot byte code and run it. Thereby, utilising all the good stuff that preceeds the VM interpreter, plus probably large chunks of the parrot VM,

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Leopold Toetsch
Nigel Sandever [EMAIL PROTECTED] wrote: [ Line length adjusted for readability ] VIRTUAL MACHINE INTERPRETER At any given point in the running of the interpreter, the VM register set, program counter and stack must represent the entire state for that thread. That's exactly, what a

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Leopold Toetsch
Nigel Sandever [EMAIL PROTECTED] wrote: On Sat, 03 Jan 2004 01:48:07 -0500, [EMAIL PROTECTED] (Uri Guttman) wrote: your ideas make sense but only on redmond/intel which is not the target space for parrot. s/not the/by far not the only/ Maybe it would be possible (for me + others) to write

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Uri Guttman
LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT These are platform specific details. We will use whatever the LT platform/OS provides. In the source code its a LOCK() UNLOCK() pair. LT The LOCK() can be any atomic operation and doesn't need to call the LT kernel, if the lock is

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Elizabeth Mattijsen
At 12:15 -0500 1/3/04, Uri Guttman wrote: LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT These are platform specific details. We will use whatever the LT platform/OS provides. In the source code its a LOCK() UNLOCK() pair. LT The LOCK() can be any atomic operation and doesn't need to

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Nigel Sandever
On Sat, 3 Jan 2004 11:35:37 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote: Nigel Sandever [EMAIL PROTECTED] wrote: VIRTUAL MACHINE INTERPRETER At any given point in the running of the interpreter, the VM register set, program counter and stack must represent the entire state for

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Elizabeth Mattijsen
At 18:20 + 1/3/04, Nigel Sandever wrote: Sharing data between the threads/interpreters is implemented by tieing the two copies of the variables to be shared and each time a STORE is performed in one thread, the same STORE has too be performed on the copy of that var held on every other

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Elizabeth Mattijsen
I'm trying to be constructive here. Some passages may appear to be blunt. Read at your own risk ;-) At 01:48 -0500 1/3/04, Uri Guttman wrote: NS == Nigel Sandever [EMAIL PROTECTED] writes: NS All that is required to protect an object from corruption through NS concurrent access and

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Jeff Clites
On Jan 3, 2004, at 11:19 AM, Elizabeth Mattijsen wrote: At 01:48 -0500 1/3/04, Uri Guttman wrote: NS == Nigel Sandever [EMAIL PROTECTED] writes: NS All that is required to protect an object from corruption through NS concurrent access and state change is to prevent two (or more) VMs NS

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Jeff Clites
On Jan 3, 2004, at 10:08 AM, Elizabeth Mattijsen wrote: At 12:15 -0500 1/3/04, Uri Guttman wrote: LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT These are platform specific details. We will use whatever the LT platform/OS provides. In the source code its a LOCK() UNLOCK() pair. LT

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Leopold Toetsch
Nigel Sandever [EMAIL PROTECTED] wrote: On Sat, 3 Jan 2004 11:35:37 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote: That's exactly, what a ParrotInterpreter is: the entire state for a thread. This is only true if a thread == interpreter. If a single interpreter can run 2 threads then that

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Uri Guttman
EM == Elizabeth Mattijsen [EMAIL PROTECTED] writes: ding! ding! ding! you just brought in a cpu specific instruction which is not guaranteed to be on any other arch. in fact many have such a beast but again, it is not accessible from c. EM I just _can't_ believe I'm hearing this. So

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Uri Guttman
LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT Uri Guttman [EMAIL PROTECTED] wrote: LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT These are platform specific details. We will use whatever the LT platform/OS provides. In the source code its a LOCK() UNLOCK() pair. LT The

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Uri Guttman
EM == Elizabeth Mattijsen [EMAIL PROTECTED] writes: EM At 12:15 -0500 1/3/04, Uri Guttman wrote: LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT These are platform specific details. We will use whatever the LT platform/OS provides. In the source code its a LOCK() UNLOCK() pair. LT

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Dave Mitchell
On Sat, Jan 03, 2004 at 08:05:13PM +0100, Elizabeth Mattijsen wrote: At 18:20 + 1/3/04, Nigel Sandever wrote: Sharing data between the threads/interpreters is implemented by tieing the two copies of the variables to be shared and each time a STORE is performed in one thread, the same

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Jeff Clites
On Jan 3, 2004, at 12:26 PM, Uri Guttman wrote: LT These are platform specific details. We will use whatever the LT platform/OS provides. In the source code its a LOCK() UNLOCK() pair. LT The LOCK() can be any atomic operation and doesn't need to call the LT kernel, if the lock is

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Nigel Sandever
On Sat, 3 Jan 2004 21:00:31 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote: That's exactly, what a ParrotInterpreter is: the entire state for a thread. This is only true if a thread == interpreter. If a single interpreter can run 2 threads then that single interpreter cannot

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Uri Guttman
JC == Jeff Clites [EMAIL PROTECTED] writes: JC On Jan 3, 2004, at 12:26 PM, Uri Guttman wrote: that could be workable and might be faster. it does mean that locks are two step as well, user space test/set and fallback to kernel lock. we can do what nigel said and wrap the test/set in

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Elizabeth Mattijsen
At 21:11 + 1/3/04, Dave Mitchell wrote: On Sat, Jan 03, 2004 at 08:05:13PM +0100, Elizabeth Mattijsen wrote: Actually, you can bless a reference to a shared variable, but you can't share a blessed object (the sharing will let you lose the content of the object). I think shared compound

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Leopold Toetsch
Uri Guttman [EMAIL PROTECTED] wrote: ok, i missed the 'if' there. :) that could be workable and might be faster. it does mean that locks are two step as well, user space test/set and fallback to kernel lock. Yep, that is, what the OS provides. I really don't like to reinvent wheels here -

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Leopold Toetsch
Uri Guttman [EMAIL PROTECTED] wrote: ... this again brings up how we lock so that GC/alloc will work properly with threads. do we lock a thread pool but not the thread when we access a shared thingy? This is the major issue, how to continue. Where are shared objects living (alloc) and where

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Leopold Toetsch
Elizabeth Mattijsen [EMAIL PROTECTED] wrote: Indeed. But as soon as there is something special such as a datastructure external to Perl between threads (which happens automatically shared automatically, because Perl doesn't know about the datastructure, Why is it shared automatically? Do

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Leopold Toetsch
Nigel Sandever [EMAIL PROTECTED] wrote: On Sat, 3 Jan 2004 21:00:31 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote: Yep. So if a single interpreter (which is almost a thread state) should run two threads, you have to allocate and swap all. When a kernel level thead is spawned, no

Re: Threads Design. A Win32 perspective.

2004-01-03 Thread Jeff Clites
On Jan 3, 2004, at 2:59 PM, Leopold Toetsch wrote: Nigel Sandever [EMAIL PROTECTED] wrote: Only duplicating shared data on demand (COW) may work well on systems that support COW in the kernel. No, we are dealing with VM objects and structures here - no kernel is involved for COWed copies of e.g.

Re: Threads Design. A Win32 perspective.

2004-01-02 Thread Nigel Sandever
On Thu, 01 Jan 2004 21:32:22 -0500, [EMAIL PROTECTED] (Uri Guttman) wrote: UG Uri Guttman NS Nigel Sandever. (Mostly not reproduced here!) NS REENTRANCY UG this is true for c level threads but not necessarily true for VM level UG threads. f the VM is atomic at its operation level and can't

Re: Threads Design. A Win32 perspective.

2004-01-02 Thread Uri Guttman
NS == Nigel Sandever [EMAIL PROTECTED] writes: NS ATOMICITY AND CRITICAL SECTIONS UG that is what i mentioned above, disabling time slicing/ preemption when UG desired. it is not just a win32 concept. hell, turning off interrupts UG during interrupt handlers goes way back! redmond just

Threads Design. A Win32 perspective.

2004-01-01 Thread Nigel Sandever
This is going to be extremely light on details with respect to the current state of the Parrot interpreter. It is also going to be expressed in terms of Win32 APIs. For both of these I apologise in advance. Time, and the or forever hold your peace imperative has overridden my desire to do

Re: Threads Design. A Win32 perspective.

2004-01-01 Thread Uri Guttman
NS == Nigel Sandever [EMAIL PROTECTED] writes: NS REENTRANCY NS Not only must the VMI be coded in a reentrant fashion, with all state NS addressed through pointers (references) loaded into it's Virtual NS register set. All the code underlying it, including syscalls and CRT NS must