From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-07 17:37:54
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk