Re: [boost] Re: boost.threads

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-07 17:37:54

williamkempf_at_[hidden] wrote:
 
> So, what's really needed are two different keywords for two new types
> of declarations: synch and thread_local.  Types declared as "synch"
> are gauranteed to be initialized only once regardless of attempts by
> multiple threads to do so.  Types declared as thread_local are
> created/initialized at first use with seperate instances for each
> thread that does so.

        Aha! Very interesting. In Felix, there are three 'frames'
which must be passed to every routine:

        1. Global data frame -- constants only, perhaps a clock image
        2. Process frame -- one per process
        3. Thread frame -- one per OS thread

Felix itself provides 'ultralightweight threads', that is,
cooperatively multi-tasked threads, and these are represented
directly by 'stack frames' it creates. I put 'const' values in
the global frame, and all other non-function local data
(including, incorrectly, the garbage collector) in the 
thread frame. [The process frame is intended for sharing
data between OS threads]

I've been wondering if this scheme is adequate, and how
to annotate the data to indicate where to put it.
Your model basically suggests:

        const --> global frame 
        synch --> process frame
        thread_local --> thread frame 
        other 'static' --> UL thread data
        function local --> per function invocation (stack frame)

The three main 'frames' are single C++ objects (at present),
and the user constructs them, so the 'once' problem goes
away.

Do you think there is any point in a more generalised
sharing model? Say, user defined 'levels' of sharing?

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net