Showing posts with label preemptive. Show all posts
Showing posts with label preemptive. Show all posts

2012-08-31

parasail is big win for reliable concurrency

12.7.2: news.adda/co/ParaSail
(Parallel Spec and Impl Lang) is by Ada's Tucker Taft:

first siting of parasail:
11/09/11 Language Lessons: Where New
Parallel Developments Fit Into Your Toolkit

By John Moore for Intelligence In Software
The rise of multicore processors and programmable GPUs
has sparked a wave of developments in
parallel programming languages.
Developers seeking to exploit multicore and manycore systems
-- potentially thousands of processors --
now have more options at their disposal.
Parallel languages making moves of late
include the SEJITS of University of California, Berkeley;
The Khronos Group’s OpenCL;
the recently open-sourced Cilk Plus;
and the newly created ParaSail language.
Developers may encounter these languages directly,
though the wider community will most likely find them
embedded within higher-level languages.

. ParaSail incorporates formal methods such as
preconditions and post-conditions,
which are enforced by the compiler.
In another nod to secure, safety-critical systems,

2012-06-14

architectures that prevent freezing #mac

5.9: sci.cyb/mac/architectures that prevent freezing:
to: cocoa-dev@lists.apple.com
. in a pre-emptive OS there should be no freezing;
given the new concurrency model
that includes the use of the graphics processor GPU
to do the system's non-graphics processing,
my current guess is that the freezes happen when
something goes wrong in the GPU,
and the CPU is just waiting forever .
. the CPU needs to have some way of getting control back,
and sending an exception message to
any of the processes that were affected by the hung-up GPU .
. could any of Apple's developers
correct this theory or comment on it ?

2012-05-17

reliable drivers for monolithics #linux

5.17: summary:
. many of the crashes we endure on rock-solid linux
are due to device driver errors .
. here are my edits of several papers that offer hope
by transitioning drivers to an event-based architecture .

4.23: news.cyb/sec/reliable drivers for monolithics:
Leonid Ryzhyk(Ph.D. 2009)`
On the Construction of Reliable Device Drivers
Previous research on driver reliability
has concentrated on detecting and mitigating
defects in existing drivers
using static analysis or runtime isolation.
In contrast,
this dissertation presents an approach to
reducing the number of defects
through an improved  device driver architecture
 and development process.
This implementation allows our reliable drivers
to coexist with conventional Linux drivers,
providing a gradual migration path .

2010-07-27

adda's virtual preemptive multitasking

 7.4: adda/translate/tasklets:

. tasklet here means
a chunk of app that is considered by
the task scheduler to be
a unit of time slicing,
allowed to be run uninterrupted .
. it comes from Ada's "(task),
a thread of execution,
and is a way of translating c's
single-threaded model
into a multi-threaded one .
--
. definitions of tasklet by others
include stackless`threads
and linux:
"(Tasklets are a deferred-execution method
as a way for interrupt handlers to schedule work
to be done in the very near future.
a tasklet is a function(of data pointer)
to be called in a software interrupt
as soon as the kernel finishes running
an interrupt handler .
)[7.7:
. app's are calling to the system
only for system resources:
for things they need permission to share
like ipc, and file sharing .]
. if app's have to call back
to system for so much,
why chop them into tasklets?
. why can't apps simply
call task mgt periodically
and in every loop ?
#:
. also need to watch for
mutual recursion loops
where stack over-use
is more dangerous than time hogging .
#:
. periodic calls to system might work for
multi-tasking system work
like when an app gives the system's
controller-view obj's a chance to
interact with user;
but, for giving many concurrent app's
a fair share of time slices,
that requires tasklets .

. c has no concept of threads,
each with their own stack,
so c's one system stack must be reserved for
only the tasklet-running system;
the calls to apps are not c calls at all .

tasklets are modeled from asm:
. each thread's program
is an array of tasklets;
pc: index into array of tasklets;
sp: ptr to thread's stack;
task mgt calls are
(thread#pc)(sp) .

7.6: adda/tasklets/goto's:
. the tasklet plan is complicated by
the looping made by goto's?
just treat each loop's {entry, exit} points
as instructions,
and the blocks between those instr's
will be tasklets .
. this will put at least 2 yield points
in every loop .

adda/tasklets/declare.blocks:
. recall nested declare.blocks
can create new locals,
so at level#n,
the thread has a local's array
with n ptrs to [decl'block` act'rec]'s
(one for each nest level) .

7.7:
. threads do need their own artificial stack:
each call to another sub
is considered a tasklet
unless it's calling a sub that is so brief
that it hasn't been broken into tasklets .
[7.27:
. there's basically 2 kinds of calls:
app calls that run an algorithm;
and type'mgt calls that do
brief operations on their members .
app calls are kept on the thread's
artificial stack,
whereas, calls to brief operations
are allowed to run on the c`stack .]

. one way is already written:
"(. all c routines
take an arg of where to start .
. the routine exits by returning
what step it should continue at .
)
-- if that is written somewhere
it's a defunct writing:
.the better way is to replace all calls
with the system's style of calls .

. I'm worried that any arificial stack idea
will be no more efficient than
just doing vm code?

. every artificial call
becomes a stack & exit
but not every call
needs to be a separate tasklet .

. also, the tasklet idea is meant only for
the app's that want multi-threading;
so, tasklets can be as unresponsive
as app's can tolerate;
adda's insured gui response,
on the other hand,
comes from adda embedding code into app's,
so that all code is frequently
calling the system to handle real-time .