On Tue, 2 Sep 2003, Timothy Stack wrote: > > > > I am part of a team porting Kaffe to a Cray. I would like to find someone > > who has an understanding of why the locks were implemented with hidden stack > > variable (the "where" in _lockMutex). It is causing great consternation in > > light of the Cray stack. > > Can you explain whats unique about the cray stack or give a pointer?
Unicos starts by allocating a relatively small stack. Every function that uses the stack has a preamble that checks to see if the stack is large enough, and if it is not, it calls a function with the enigmatic name of $STKOFEN. $STKOFEN first tries to increase the size of the stack to the required amount, but if this is not possible (because the memory after the stack is already allocated) it will allocate another block (using what is essentially malloc). A structure at the end of each stack segment contains an offset that can be used to find the previous segment, so the stack is essentially a linked list. $STKOFEN also manipulates the call stack so that the function that caused a new block to be allocated will return to a deallocation routine, which after deallocating jumps to the true return address. > > It also seems rather hostile to someone trying to > > use a mutex, since it is not documented very well. I have changed locks to > > use a structure within locks itself and tracking the TID of the lock holder. > > Is there someone that could comment on this approach? > > Can you elaborate on this? The latte project, an offshoot of kaffe, have > a superior lightweight lock implementation, rolling those in might be > better. > > > We are also finding that the debug code is not very friendly on an MP. The > > movement of data to the debug buffer is not protected by a mutex and, thus, > > becomes a difficult tool. Is there anyone that has ported Kaffe to an MP? > > dunno, but, I would imagine there are many many race conditions. Truly kaffe has never been run on an SMP box before? That's surprising. > Can you use the user-level threading implementation instead of native > threads, atleast for now? There are two problems with that that I see: 1) the user-level threads make even more use of carnal knowledge of the stack. Since the cray stack is nothing like the stack that code assumes, porting will be fun. 2) the stock cray longjmp frees any stack segments allocated by the calls in-between the setjmp call and longjmp, and is therefore not usable for the setjmp/longjmp threading trick. There is a replacement setjmp/longjmp implementation floating around, but it never deallocates stace segments, causing them to be leaked, and causes data corruption for some reason. Rockwalrus _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe