By adding a counter to count the number of
section of codes from the processing queue loading to the generic processors,
we could estimate when to load the delayed codes back to an idle processor. For
example, after 3 loads of codes the delayed codes would be loaded back to a
processor. This counter could be dynamically adjusted if “3” was not a best
guess.
12. Preloading data in memory to
each processor
12.1 Concurrent main memory
access
Going
down to microprocessor level, concurrent memory “write” access is not possible,
i.e. only one microprocessor could write to memory at a time. However many
processors could read data from memory at the same time.
If
we could equip each generic processor (and specialized processor), which
include a microprocessor with cache, with preloading data (variables) required
in each section of codes, the processing time could faster for the entire
system. In brief, each microprocessor could write and read preloaded data in
each own cache memory in parallel.
There
is a case that caused preloading data didn’t work as stated above. Software
developers could write a section of codes that require reading and writing into
database of main memory within that section.
To
permit many processors to preload data in many sections of codes
simultaneously, we could implement a few flags in the hardware or operating
system for memory and for each processor such as
-
Memory flag could be RedW (red-write) when a write operation is in
progress. Memory flag could be RedR (red-read) when a read operation(s) is in
progress.
-
Processor write flag green means that it’s writing data into the
main memory. The main Memory flag would be set to RedW in this case. When it
finished writing, it could set its Processor write flag to red.
-
Processor Write flag yellow means that it’s waiting to write into
the main memory. This process must be in the “waiting queue” or wait if the Memory
flag is still RedW or RedR. If the Memory flag is green, it can start to write
& set the Memory flag to RedW.
-
Processor Read flag is yellow means that the generic processor is
ready to read data from the memory.
-
Processor Read flag is green means that the generic processor is
reading data from memory. After reading data from main memory, it could set the
Processor Read flag to Red. During reading from the main memory, the Memory
flag is set to RedR. Unless parallel reading is permitted or no-conflict, all
processors could read data at the same time.
-
The operating system would coordinate the whole system. If the
Memory flag is RedR or RedW, one or more Processor Write flag is green, and one
or many Processor Read flags are yellow; it would wait for the current writing
process finished to change the Memory flag to green.
o
Change the Processor Read yellow flags to green
o
It allows all reading process to preload data into cache of each
processor; set the Memory flag to RedR.
o
In this case, all pending Processor Write flag yellow must wait
until the reading process completed and the Memory flag back to green again.
-
If all Processor Write flags are yellow and Memory flag is green,
the system would allow all pending Read process started.
-
If the Memory flag is RedR and a processor has the Read flag as
yellow, operating system should let that processor reads data from the main
memory.
-
If a read or write operation is in progress, the Memory flag
should be redR or redW. If there is no read/write operation occurs, the Memory
flag is green.
The
above process would be better illustrated in a flow chart.
12.2 Handling of pre-load variables in a processors
As
described in the section Concurrent Main
Memory Access, the process of read and write to main memory is complicated.
System would slow down considerably if there are many read and write operations
required for the same section of codes.
a.
Typical case where each variable is process once
During
preloading data, each variable would be stored in a place holder in the cache
of each processor. A place holder is associated with a memory address in main
memory or a hard disk.
At
the end of code execution, “changed or written” permanent data in the place
holders would be transferred to the main memory.
b.
A variable is processed several times in a section of codes
There
is a case that a program statement reads a value from main memory into a
variable; writes new value into that variable; and then used the same variable
again in the same section of codes. This would normally require a write access
to main memory for writing new value, and then a read of that value again in
those statements.
In
order to save a write access to main memory during execution of this section,
some flags could be used during compiling the application to note the above
scenario, so only one write access would be required at the end of execution of
that section of codes, i.e. a write operation in the middle of codes was not
required.
During
the first pass of compilation of codes, the compiler would notice the same
variable used several times in the section. In the second compiling pass, the
compiler marked that the first use of this variable would require a Read value
from main memory into a place holder in cache memory. The second updating of
this variable would be writing new value into this place holder. The third use
of this variable would be a read from this holder in this cache instead to
reading from main memory.
At
the end of code execution, only “changed or written” permanent data in the
place holders would be transferred to the main memory.
13. Parallel memory
The
main memory couldn’t handle concurrent writing by many microprocessors at a
time, because it could create a scenario like “data corrupted” in the
application.
System
could create several memory spaces and let application developers used
variables in each memory space separately. This would help concurrent writing
process. In term of hardware, there would be separate data bus to each memory space.
Variables
without any prefix below used the previous memory space.
This
could be done by using different set of prefix for variables. For example,
-
Variables start with “S1_” means variable stored in memory space
1.
-
Variables start with “S2_” means variable stored in memory space 2.
A system could be upgraded with parallel memory even
if system had been deployed in the field. New applications only need to use
appropriated prefix recognized by the parallel memory space. Hardware and
operating must be upgraded by the way, but they could keep existing
applications intact.
Parallel memory
would be supported by separate buses from the mother board to its hard disk
(RAM is similar with separated buses). The hard disk is like a cylinder with (2)
different platters attached to an axis. There
would be reading heads, e.g. 2 reading heads for 2 platters, rotating around the
axis and access information on different locations of data on 2 platters in
parallel.
14. Miscellaneous notes
14.1 Special Syntax
The special deliver queue was removed from the
diagram, because the syntax and examples didn't support it.
If it's needed, syntax in addition to EXEC and SP_PROCESS must be used. For example, in the statement SP_Queue SP_LocateServer (zone1,
zone2, zone3), the signal SP_LocateServer would be placed in the Special Delivery Queue waiting to be delivered
to a program section. Depending on the operating system allocation, the signals
loaded on the special delivery queue could be delivered to its destination
faster.
If the SP_Queue command was not implemented the
special codes could send a signal using regular Delivery Queue.
The syntax SEND could be replaced by the syntax QUEUE,
i.e. same functionality. These statements are to place a signal with data in
the processing queue.
Figure 2. Specialized processor with delivery
queue
As described in section 1, the function SP_Display3dReport has prefix of “SP_”, which could be used in a special
implementation. For example, a system provider could come up a special library
and specialized processor.
·
Register
a specialized processor with OS including a special prefix
·
By
loading the library to the IDE for programming language, the IDE would allow
users to specify the special prefix to all those added functions in the
library.
·
Software
developers would use those functions in library as usual.
·
The
OS would load all functions with that special prefix in specialized processors
for processing.
This way of implementation is slower in processing
than using the syntax SP_PROCESS. However this option is probably the best
choice for Windows OS shared or used by many users and applications providers,
because they don’t need to pre-configure a specialized processor and used the
syntax SP_PROCESS or SP_QUEUE.
Multiple Monitors
To help stock traders or software developers, who have been using
multiple monitors in their tasks, we could design a 4-screen or 4-monior laptop.
The additional top (ID = 01), right (ID = 11), left (ID = 10) monitors could be
pulled out from the regular/main monitor laptop (ID = 00) to make the laptop
with 4 screens. Manufacturers could add 3 more (touch) keyboards underneath of
the regular keyboards, which control a specific monitor.
Figure 3. Layout of multiple monitor system
The communications between software application and each monitor
was described in the figure 3. Each monitor is uniquely identified by the processor
motherboard with ID = 00, 01, 10, or 11.
As shown in the figure 3, each monitor is connected to the Monitor Dispatching Manager. When a user
start an application, main monitor would show the intended data/UI of that
application. User would normally drag any screen/UI to the monitor on the top,
left, or right for display.
There are 2 ways for the software applications communicating
correctly with the assigned monitor are
·
When the user dragged the UI to a screen the
system would relay the ID of the monitor back to the application layer and
store it for subsequent communications.
·
When the user started an application, the
application would prompt user for destination monitor, e.g. main, top, left, or
right. The application would store the monitor ID for subsequent
communications.
In the figure 3, there are only 4 monitors used, therefore system
would reserve 2 bits as ID. These 2 bits would be embedded or included in each
message processed by the OS, processor motherboard, and then sent to the Monitor Dispatching Manager. Based on
the value of these 2 bits, messages would be dispatched to correct monitor for
display.
If each application has assigned a unique ID, which is passed
through OS, processor motherboard, and toward the monitor, system does not need
to pass the monitor ID (00, 01, 10, or 11) back to the application for future processing.
The Monitor Dispatching Manager would
only associate the application ID with each monitor ID and store locally for
future communications after user dragging a UI to a specific monitor.
