[Warning] Fiber in tango.core.Thread still bug, dont use it in any scientific calculation

Mikola Lysenko mclysenk at mtu.edu
Sat Dec 8 08:32:49 PST 2007


I've used Fibers and StackThreads in several independent projects, many which happened to be heavily floating point intensive (ie 3D demos, videogames, etc).  I believe that the code used in Tango's Fibers for swapping contexts is both correct, and also more efficient than either GCC or Win32's SwapContext.  The justification for this follows from my previous argument about the cdecl calling convention, which is corroborated by the following evidence:

http://www.agner.org/optimize/calling_conventions.pdf

"Floating point registers :
The floating point registers ST(0)-ST(7) need not be saved. These registers must be 
emptied before any call or return, except for registers used for return values. ... "


I'm not exactly sure what is causing these crashes, but I can't fix any errors unless you post an example where the code breaks.  It is possible that a more serious issue than floating point state is involved, but I can't determine what is happening given the information. 

-Mik

Swer Wrote:

> I open 50 threads in my project, each threads have one master fiber and one 
> slave fiber. each salve fiber instance a LUA 5.1 lua_State*, A Lua api 
> my_yield() calling D Tango Fiber yield in my script. Lua number is double 
> type, and my master fiber will handle bothe network and DirectX. So there 
> both master/slave firbers touch FP units. My program crash randomly when 
> using Tango Fiber, but when using Win32 SwitchToFiber or Posix swapcontext 
> theres no crash anymore.
> 
> I do trace on you code by OllyDbg, there is no any FP save/restore 
> internally by C calling convention. Have u tried use your Fiber on any real 
> world project before submit to Tango library?
> 
> > Have you tried testing this with any examples?  I'm fairly certain that 
> > the FPU does actually do what it is supposed to.  If you will notice, the 
> > calling convention on the method is extern(C), not extern(D).  As a 
> > result, the C calling specification requires that the FPU state is saved 
> > before any function call by the caller - not the callee.  As a result, 
> > this method should work and moreover save a great deal of time.  Dumping 
> > the FPU state is a rather costly operation, and best avoided if possible, 
> > which is why the C calling convention works this way.
> >
> > If you can find code that breaks with the current Tango fiber 
> > implementation, I'd be happy to make the necessary changes.
> 
> 




More information about the Digitalmars-d mailing list