text:
|Publication number
|Publication type
|Application number
|Publication date
|Dec 7, 2004
|Filing date
|Mar 30, 2001
|Priority date
|Oct 4, 2000
|Fee status
|Also published as
|Publication number
|Wayne M. Cranston, Min-Yu Yang, Michael J. Purtell
|Original Assignee
|Microsoft Corporation
|Export Citation
|BiBTeX, EndNote, RefMan
|Patent Citations (14), Referenced by (46), Classifications (5), Legal Events (5)
|External Links: USPTO, USPTO Assignment, Espacenet
This application claims the benefit of U.S. Provisional Application No. 60/238,106, entitled "ExIPC", and filed on Oct. 4, 2000, which is hereby incorporated by reference.
1. The Field of the Invention
The present invention relates to interprocess communication. More specifically, the present invention relates to methods, systems, and computer program products for high-performance interprocess communication that minimizes context switches, kernel transitions, and blocking.
2. Background and Related Art
Various technologies are available for communicating information from one process to another. Among the most well-known technologies for interprocess communication are remote procedure calls ("RPC"), lightweight remote procedure calls ("LRPC"), and components based on COM or DCOM. For the most part, well-known interprocess communication techniques are general-purpose solutions that must satisfy a variety of competing interests. One significant drawback to general-purpose solutions is the need to account for the lowest common denominator, foregoing optimizations that might otherwise be available to a particular implementation. As a result, generic interprocess communication often imposes a substantial amount of overhead that tends to degrade throughput and overall performance. Among other things, interprocess communication may increase blocking, kernel transitions, and context switches, with the effect particularly pronounced when two server processes must communicate frequently in achieving a common goal or task.
Because of the higher overhead that interprocess communication is likely to introduce, programs running on a server are often written as monolithic processes to maximize performance. Nevertheless, dividing a particular task into several well-defined processes may provide a substantial benefit in simplifying program design. In choosing between potential improvements in performance versus potential improvements in program design, however, performance frequently is given more weight because end-users invariably detect slow program execution, whereas internal program design is much more difficult for end-users to quantify.
When multiple processes run concurrently on a single processor, the state information that distinguishes one process from another must be kept separate. Switching from one process to another requires storing the state information for the currently executing process and loading the state information for the process to be executed. The storing and loading of state information is known as a context switch. A context switch does not involve executing the instructions of a particular process to achieve a given goal or task; rather, a context switch is merely preparation for executing the instructions of a particular process. The more time spent switching from one process to another, the less time available for running the processes themselves. Of course, some environments may include excess computing resources or sufficient user interaction such that context switches do not represent a significant burden. In other environments, however, especially environments where one process provides one or more services to other processes, context switches may represent a significant amount of processing time that would boost performance if eliminated or reduced.
One way to diminish the impact of context switches is to shrink the amount of state information that must be stored and loaded. So-called lightweight processes or threads are directed largely toward to goal of minimizing state information and the corresponding performance detriments of context switching. Nevertheless, although reduced in extent, whether context switches involve processes or some type of lightweight counterpart, the execution time required for storing and loading context information diminishes performance. Naturally, as the number of competing processes increases, the amount of processor time devoted to context switching may increase as well. Because many of the issues involving interprocess communication are similar for processes, threads, lightweight processes, etc., the term "process" as used throughout this application should be interpreted as a generic term that encompasses all entities capable execution, including threads, lightweight processes, and the like.
Another factor to consider in evaluating the performance of interprocess communication is the execution time required to marshal data. Data marshaling accounts for system or process differences. For example, the address space of one process may be distinct from the address space of another process, one process may represent data differently from another, etc. Therefore, marshaling generally includes copying parameters, return values, and/or other exchanged data from one process to a shared memory area and then from the shared memory area to another process. As part of the copying, data may be formatted in a portable structure to account for any differences in how the processes represent data. Depending on the data to be exchanged, data marshaling may involve copying, probably multiple times, large amounts of data from one memory location to another. Like context switches, marshaling data is overhead to interprocess communication in which a particular process does not make further progress in achieving its goal or task, but rather, simply prepares for making progress.
At times, one process may need one or more services that another process provides. In using the services of another process, one process often communicates parameters and/or data to the process implementing the needed services and waits for a response. While waiting, the process is "blocked." Blocking is a mixed bag of sorts. A blocked process does not receive any execution time because it is unable to run. By blocking, the process will not be available for a context switch that, if it occurred, would be followed immediately by another context switch because the blocked process cannot continue further processing until it receives a response. Thus, in one sense, blocking saves unproductive context switches. At the same time, however, blocking virtually guarantees one or more context switches. As soon as a process blocks, another process must be selected to run, resulting in one context switch. Then, at a later time when the blocked process receives its response, another context switch occurs to allow the now unblocked process to continue execution.
To illustrate as least some of the foregoing problems, consider the following overview of LRPC. As indicated above, LRPC stands for local remote procedure call and differs from RPC mostly in its underlying implementation. LRPC is used for RPC calls that stay on the same machine, as automated by the RPC subsystem. Rather than network transfer, LRPC uses shared memory for data transfer.
As a specific example, consider LRPC communication between process A and process B. Process A calls into its side of an RPC handler which marshals its data into shared memory, signals process B to handle the call, and then blocks the thread until process B signals that it has completed the request. Process B wakes up when signaled, unmarshals the shared memory data, and calls the registered function with the unmarshaled parameters. Process B waits for the function to return, marshals any return data into shared memory, and then signals process A that it is done. Process A then wakes up, unmarshals the return data, and the RPC routine returns to the caller. Note that LRPC involves multiple context switches, a significant amount of data marshaling, and synchronous interprocess communication that blocks further process execution.
The present invention provides for high-performance interprocess communication without the prohibitive overhead that may be imposed by prior art techniques. During an initialization phase, each side dynamically identifies one or more routines that are responsible for handling communication received from other processes. Communication between processes occurs through a shared memory heap and a shared memory queue. Allocations from the shared memory heap produce a process agnostic memory handle and a process specific memory pointer. Using the memory pointer, the enqueuing process places an operation code, parameters, and any other relevant data in the allocated memory. The enqueuing process then adds the memory handle to the shared memory queue. The dequeuing process uses the memory handle from the shared memory queue to generate a valid memory pointer so that the allocated shared memory can be accessed in the dequeuing process. By allowing direct access to shared memory in each process, the present invention may reduce the amount of data marshaling that otherwise may be required. Upon retrieving the operation code that was placed in the allocated memory, the dequeuing process calls the routine, identified during the initialization phase, that corresponds to the operation code.
When an enqueuing process expects a response back from the dequeuing process, the request may be registered. Upon receiving the response, the enqueuing process removes the request from the register. However, if the dequeuing process is unable to respond, the enqueuing process uses the registration information to free resources allocated to the request and perform any other needed cleanup operations. The dequeuing process may be unable to respond due to a variety of circumstances. For example, the dequeuing process may be shutting down for some reason or the dequeuing process may have experienced a catastrophic failure and been terminated. Thus, depending on the circumstances, the dequeuing process may notify the enqueuing process that it will not respond to any outstanding requests.
The enqueuing and dequeuing operations are asynchronous, thereby allowing multiple enqueues and/or multiple dequeues without a context switch. A signaling arrangement may be used by the enqueuing process to notify the dequeuing process of memory handles that have been added to the shared memory queue. Through the signaling arrangement, the enqueuing process and dequeuing process may help each other in determining the resources that should be devoted to removing memory handles from the shared memory queue and processing the corresponding operation codes. Furthermore, the enqueuing process may reserve space for a response in the shared memory queue. The reserved space assures that the response will not be delayed or cause significant processing overhead due to a fall queue. For example, without reserved space, a response may need to be retried repeatedly until it succeeds or placed on a retry queue which may grow without bound.
In one implementation, the present invention has been used in providing access to content. One process is responsible for content operations and another process is responsible for connection operations. The connection process includes a controller and a bi-directional queue for each supported protocol. A completion port and thread manager pool threads available for dequeuing operations, and a registration controller tracks enqueued communication where a response is expected. Similarly, the store process also includes a controller for each supported protocol, a completion port and thread manager for pooling threads available for dequeuing operations, and a registration controller for tracking enqueued communication where the store process expects a response. Both the connection process and the store process identify handler routines for the operation codes associated with each supported protocol.
Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.
In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered as limiting its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
FIG. 1 illustrates an exemplary system that provides a suitable operating environment for the present invention;
FIG. 2 is a block diagram of an embodiment of the present invention used in providing access to content;
FIG. 3 shows a life-cycle flow diagram corresponding to the embodiment depicted in FIG. 2;
FIG. 4 is an application program interface or API representation of high-performance interprocess communication in accordance with the present invention;
FIG. 5 illustrates an exemplary process agnostic memory handle;
FIG. 6 is a flow diagram of shared memory allocation from one or more shared memory block heaps; and
FIGS. 7A-7B show an exemplary method of high-performance interprocess communication according to the present invention.
The present invention extends to methods, systems, and computer program products for high-performance interprocess communication. Processes communicate with each other through a shared memory heap and a shared memory queue. An enqueuing process places an instruction and possibly other data in memory allocated from the shared memory heap and adds a process agnostic memory handle to a shared memory queue. A dequeuing process removes the process agnostic memory handle from the shared memory queue and processes the instruction using routines that are identified dynamically. The embodiments of the present invention may comprise a special purpose or general purpose computer including various computer hardware, as discussed in greater detail below.
Embodiments within the scope of the present invention also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media which may be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media. Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions.
FIG. 1 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by computers in network environments. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represent examples of corresponding acts for implementing the functions described in such steps.
Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
With reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a conventional computer 20, including a processing unit 21, a system memory 22, and a system bus 23 that couples various system components including the system memory 22 to the processing unit 21. The system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM) 24 and random access memory (RAM) 25. A basic input/output system (BIOS) 26, containing the basic routines that help transfer information between elements within the computer 20, such as during start-up, may be stored in ROM 24.
The computer 20 may also include a magnetic hard disk drive 27 for reading from and writing to a magnetic hard disk 39, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from or writing to removable optical disk 31 such as a CD-ROM or other optical media. The magnetic hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive-interface 33, and an optical drive interface 34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-executable instructions, data structures, program modules and other data for the computer 20. Although the exemplary environment described herein employs a magnetic hard disk 39, a removable magnetic disk 29 and a removable optical disk 31, other types of computer readable media for storing data can be used, including magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, RAMs, ROMs, and the like.
Program code means comprising one or more program modules may be stored on the hard disk 39, magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including an operating system 35, one or more application programs 36, other program modules 37, and program data 38. A user may enter commands and information into the computer 20 through keyboard 40, pointing device 42, or other input devices (not shown), such as a microphone, joy stick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 21 through a serial port interface 46 coupled to system bus 23. Alternatively, the input devices may be connected by other interfaces, such as a parallel port, a game port or a universal serial bus (USB). A monitor 47 or another display device is also connected to system bus 23 via an interface, such as video adapter 48. In addition to the monitor, personal computers typically include other peripheral output devices (not shown), such as speakers and printers.
The computer 20 may operate in a networked enviromnent using logical connections to one or more remote computers, such as remote computers 49 a and 49 b. Remote computers 49 a and 49 b may each be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically include many or all of the elements described above relative to the computer 20, although only memory storage devices 50 a and 50 b and their associated application programs 36 a and 36 b have been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local area network (LAN) 51 and a wide area network (WAN) 52 that are presented here by way of example and not limitation. Such networking environments are commonplace in office-wide or enterprise-wide computer networks, intranets and the Internet.
When used in a LAN networking environment, the computer 20 is connected to the local network 51 through a network interface or adapter 53. When used in a WAN networking environment, the computer 20 may include a modem 54, a wireless link, or other means for establishing communications over the wide area network 52, such as the Internet. The modem 54, which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules depicted relative to the computer 20, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing communications over wide area network 52 may be used.
FIG. 2 is a block diagram of an embodiment of the present invention that includes Internet Information Server ("IIS") process 220 a communicating with store process 220 b through shared memory 210. Shared memory 210 includes a shared memory heap ("SMH") 212 and one or more shared memory queues ("SMQs") 214, wherein shared memory heap 212 comprises one or more block heaps. When allocating shared memory, SMH 212 provides a process agnostic memory handle that may be exchanged between IIS process 220 a and store process 220 b through SMQs 214. One process places an instruction, parameters, other relevant data, etc. in the allocated shared memory where they may be accessed by the other process.
Store process 220 b is responsible for managing content operations and IIS process 220 a is responsible for managing connection operations. In this embodiment, IIS process 220 a is a client requesting content from a server, store process 220 b. In general, a client is a consumer of resources and a server is a provider of resources. Those of skill in the art will recognize, however, that a server in one context may be a client in another context. Likewise, a client in one context may be a server in another context. As used in this application, therefore, the terms client and server should not be interpreted as mutually exclusive. Furthermore, it should be emphasized that the present invention may be practiced between any arbitrary processes. Communication between a client process and a server process, as shown in FIG. 2, is merely exemplary and should not be viewed as limiting the scope of the present invention.
IIS process 220 a supports connections over a variety of communication protocols 230 a, including simple mail transfer protocol ("SMTP") 231 a, Internet messaging protocol version 4 ("IMAP4") 233 a, distributed authoring and versioning protocol ("DAV") 235 a, post office protocol version 3 ("POP3") 237 a, and network news transfer protocol ("NNTP") 239 a. Note that store process 220 b supports access to content over corresponding communication protocols 230 b, namely simple mail transfer protocol ("SMTP") 231 b, Internet messaging protocol version 4 ("IMAP4") 233 b, distributed authoring and versioning protocol ("DAV") 235 b, post office protocol version 3 ("POP3") 237 b, and network news transfer protocol ("NNTP") 239 b. Those of skill in the art will recognize that the present invention is not necessarily limited to supporting any particular protocol.
ExIPC 240 a is responsible for handling interprocess communication on the IIS process 220 a side and ExIPC 240 b is responsible for handling interprocess communication on the store process 220 b side. Each communication protocol 230 a and 230 b has a dedicated bi-directional shared memory queue ("SMQ" or simply "queue") 214, with a single SMQ controller 244 a and 244 b on each side of the communication. For the embodiment of FIG. 2, each SMQ 214 is a pair of unidirectional shared memory queues. The SMQ controllers 244 a and 244 b manage enqueue operations and use a completion port and thread manager to pool threads that are available for dequeuing operations. Memory management operations on shared memory heap ("SMH") 212 are performed by SMH controllers 242 a and 242 b. Registration controllers 246 a and 246 b track enqueued communication where a response is to be guaranteed.
FIG. 3 shows a life-cycle flow diagram corresponding to the embodiment depicted in FIG. 2. More detail will be provided with respect to the discussion of FIGS. 4-6. During protocol registration 310, each side registers the protocols that it supports and expects to use, and one side creates a SMQ for each of the registered protocols. Binding 320 identifies the completion port that will be used to pool threads for a particular queue and insures that each side has registered a protocol, so that an endpoint exists for each side of the communication that will occur. Communication between the processes includes a series of enqueues/dequeues 330 of process agnostic memory handles using the SMQ. (Each memory handle corresponds to an allocation from the SMH that contains an instruction and any data needed or useful in processing the instruction.) Remote protocol disconnect/remote process termination 340 indicates that one side of the communication is no longer able to function, either for a particular protocol or for all protocols. Upon receiving a shutdown notification 350 from the remote process, the local process NAKs registered packets 360. After NAKing registered packets 360, shutdown is complete 370, the SMQ is released, and the local process has at least two options: attempt local protocol reconnect/local process termination 380. Reconnection begins with creating a new SMQ in protocol registration 310 as identified above.
FIG. 4 is an application program interface ("API") representation of high-performance interprocess communication in accordance with the present invention. More specifically, FIG. 4 shows the sequence of function calls used for communication between process A 410 and process B 420. Running process A 410 and process B 420 on separate processors may significantly reduce the number of context switches that occur, but the achieving the benefits the present invention does not require the use of multiple processors. Note that only certain parameters are shown for simplicity. Other parameters may be described in conjunction with individual routines. Furthermore, many functions include a return value that may be used for error checking. For example, functions with a prefix of "Hr" return a particular type of status as a result, functions with a "Pv" prefix return a generic pointer, and function without a prefix generally do not return any value. Those of skill in the art will recognize that a wide variety of return values and parameters may be used on connection with the present invention and that the specific details included in this application are merely exemplary.
In HrClientRegisterProtocol 432, process B 420 identifies a protocol to register, the protocol version, a global context so that handler functions can access global information about the protocol, relevant flags, handler functions or routines, an existing shared memory heap, and the version of the API. Because each protocol defines the operation codes or instructions that the protocol supports, the handler functions are protocol specific. (An operation code is an example of an instruction and should not be considered as necessarily limiting the present invention.)
HrCreateQueue(&pceqB) 434 creates a SMQ for a particular protocol, where the queue may be accessed through the "pceqB" parameter. Because each side shares a single SMQ for each protocol, only one side creates the SMQs. In many respects the decision as to which side creates the queue is somewhat arbitrary. It is only important that the SMQs are created and that a particular queue is created only one time. For the embodiment shown in FIG. 2, the client is responsible for creating the SMQs 214 (FIG. 2).
Like the call to HrClientRegisterProtocol 432 in process B 420, the call to HrStoreRegisterProtocol 438 in process A 410 identifies a protocol to register, the protocol version, a global context so that handler functions can access global information about the protocol, relevant flags, handler functions or routines, an existing shared memory heap, and the version of the API. Once each side has registered for a particular protocol and the corresponding SMQ is created, pceqB->HrBind 442 attempts to bind the queue between the two processes. In calling pceqB->HrBind 442, process B 420 identifies a hint for the maximum number of entries the SMQ will support, relevant flags, a wait time for the queue to be bound, a client side completion port that pools threads used in draining the queue, and a completion key to sort out the various status packets that may be posted to the completion port. The pceqB->HrBind 442 function will not succeed until both sides have mutually agreed on the binding for a particular protocol.
Each protocol may need to register handlers for specific operation codes or handle them in a default handler. For example, the server or store side, process A 410, registers a handler for the new queue operation code. A callback to OPC_NEWQ handler 448 allows process A 410 to set the completion port for the store side of the interprocess communication with a call to pceqA->HrSetCompletionPort 452. Recall that process B 420 set the completion port for the client side of the interprocess communication in the call to pceqB->HrBind 442.
Each side also may need other handlers, such as a handler to initiate closing an SMQ and a handler to close a queue once it has been emptied. For example, one side may need to shutdown a queue or one side may crash. By calling the other side's initiate close handler, either with an operation code or by a signal, the other side knows to stop using and to drain the queue. Once an SMQ is empty, any memory allocated from the queue is freed and the queue is released. A new SMQ can be created with the client side calling HrCreateQueue(&pceqB) 434, but the store side waits for the client side to recreate the queue.
A call to pceqB->HrSetThreadThreshold 458 specifying the minimum number of dequeue threads, the maximum number of dequeue threads, and a threshold value for when new threads should be created completes initialization for a particular protocol. Two particular types of threads are used in the embodiment shown in FIG. 2: notify threads and worker threads. Each protocol in each process includes a notify thread for receiving event signals from other processes, such as a signal for new entries in a queue, a shutdown signal, a process termination signal if another process terminates unexpectedly, etc.
When a notify thread receives a new queue entry event signal, the thread posts a completion status packet to the completion port identified in creating the SMQ. Each process implements its own thread pool, which listens on the completion port and dispatches a new or idle worker thread each time a completion status packet is received. The worker threads dequeue items from the SMQ for processing. When processing for a particular item is finished, the same worker thread is used to dequeue the SMQ until the queue is completely drained, at which time the thread is returned to the thread pool.
Some overhead is likely to accompany a new queue entry event signal, such as a process context switch, posting a completion status packet, dispatching a new or idle worker thread, etc. By implementing thread thresholds for firing new queue entry event signals, the amount of overhead may be controlled to some extent. In particular, a new queue entry event signal only occurs if the maximum number of worker threads has not been reached and the number of items in the queue divided by the threshold is greater than the current number of worker threads in the peer process.
This implies that the enqueuing process determines when its peer, the dequeuing process, needs more worker threads. The reason for this is that the enqueuing process actively knows when there are new entries in the SMQ (because it adds them) and is able to apply the foregoing logic for determining if a new queue entry event signal should be fired. Furthermore, the enqueuing process may add a number of items to the SMQ in relatively rapid succession, and then make the determination only once based on all of the newly added items.
With initialization complete, process B 420 is ready to enqueue items to the SMQ and process A 410 is ready to dequeue items from the SMQ. In the pceqB->PvAllocate(&hMem) 468 call, process B 420 allocates memory from the SMH. The resulting process agnostic memory handle, hMem, is used to obtain a pointer to the shared memory with the pMem=pceqB->PvGetPtrFromHandle(hMem) 472 call. (An exemplary process agnostic memory handle is illustrated in FIG. 5 and will be described in more detail below, following which, the allocation of shared memory from one or more shared memory block heaps will be described with reference to FIG. 6.) Either side of the process boundary, process A 410 and process B 420 can obtain a valid pointer from hMem. Those of skill in the art will recognize that memory may be accessed in a wide variety of ways, some of which may be unique to a particular programming language or environment. As such, the term pointer should be interpreted broadly to encompass all forms of memory access, including all direct and indirect forms of access, such as pointers, references, handles, etc. Using pMem, process B 420 writes to the allocated shared memory 474 as needed or desired.
Turning briefly now to FIG. 5, an exemplary process agnostic memory handle 500 is illustrated. Bit positions 510 indicate that 32 bits are used to represent the process agnostic memory handle. Fifteen bits, positions 17-31, specify a shared memory segment number 520, to distinguish between the various segments available in a particular shared memory heap. Twelve bits, positions 5-16, specify a segment offset 530 within a given shared memory segment. As noted previously, the shared memory is implemented as a block heap, meaning that each segment will be divided into one or more blocks. Five bits, positions 0-4, specify the block size of an allocation for a given process agnostic memory handle. For the embodiment shown in FIG. 2, block sizes are powers of two between 32 bytes and 32 kilobytes.
Next, the allocation of shared memory from one or more shared memory block heaps will be described with reference to FIG. 6. Each block heap comprises a table of shared memory segments ("SMSs") that are allocated and initialized on demand. As indicated with respect to FIG. 5, blocks of memory ranging from 32 bytes to 32 kilobytes are available. Therefore, an allocation request is first matched to an available block size 612 so that the appropriate block heap may be selected. For example, the requested allocation size may be rounded up to the next highest power of two. Once an appropriate block heap is identified, a hint is retrieved 616 to facilitate searching for an available free block. Each SMS has a linked list of free blocks and the hint identifies the lowest segment number that may contain a free block.
After a particular segment is identified, the segment is searched for a free block 622. If the search finds a free block in the segment ("yes" branch of decision block 624) the hint is updated 626 and that free block is used 628. When allocating, the hint is updated with the index of the segment from which the allocation occurs if the segment index is less than the hint. Similarly, when a block is freed (not shown) the hint is set to the index of the SMS of the freed block if the new index is less than the current value of the hint. Note that there is no multithreading protection for the SMS index to begin searching because it is meant to serve only as a hint of where to start searching for free blocks. If none of the blocks are held for relatively long periods of time, the result of the hint is that as the number of outstanding allocations decreases, the allocated blocks are consolidated in the lower indexes. Even though the higher indexes have allocated SMSs, their lack of use reduces the working set for the block heaps of the SMH to the lower indexes and the minimal needed working set to support the allocated blocks. The degree of success offered by this strategy, however, depends on the allocation patterns of the processes allocating shared memory.
If the search is unable to find a free block in the segment ("no" branch of decision block 624) then decision block 632 determines if there are more segments to search. If so, the next SMS in the table is selected 636 and processing continues by searching that segment for a free block 622. When the end of the table is reached at decision block 632, searching resumes at the beginning of the table and ends with the first SMS that was checked. If no free blocks are found after checking each SMS ("no" branch of decision block 632) a new segments is created or opened 642. Another process may have created a new segment that the allocating process did not identify in decision block 632. Prior to creating a new segment, a check is made to see if another process has created a new segment. Otherwise, a new segment is created by allocating and initializing a new SMS. The new (created or opened) SMS is selected 648 and processing continues by searching that segment for a free block 622.
Returning now to FIG. 4, pceqB->HrEnqueue(hMem) 478 enqueues an item to the shared memory queue by identifying the process agnostic memory handle to enqueue, the operation code for the handler on the other side, relevant flags, context information for the server and client, whether or not a serial number should be created to register the enqueued item, a status or return code if the enqueue is a response, and an identifier for a state object. At least three types of enqueue operations are supported, including a normal enqueue, an enqueue with an existing header, and an opaque enqueue. Each of these enqueue operations is described in further detail below. Note that for each type of enqueue, the use of shared memory allows for minimal or no data marshaling.
For a normal enqueue, space for the header is reserved at the front of the memory handle to be enqueued, with any data to be transferred following the memory locations reserved for the header. At enqueue, the parameters are written directly to the shared memory corresponding to the memory handle, and the memory handle is added to the shared memory queue. On the other side, the dequeuing process removes the memory handle from the SMQ and examines the flags and operation code in the header. The flags indicate the type of enqueue. After examining the flags, the dequeuing process calls the appropriate operation code handler with the parameters contained within the header. The dequeuing process is able to use the same shared memory and process agnostic memory handle in its response, if appropriate for the protocol; otherwise, the dequeuing process may free the memory associated with the memory handle.
An opaque enqueue reduces the processing to enqueue an item. No header is used in the opaque enqueue, but enough space for flags and an operation code must be reserved at the first of the shared memory corresponding to the memory handle. At enqueue, the memory handle is added to the shared memory queue, but any information other than the operation code and flags is written to the shared memory. A separate function call is used for opaque enqueues given the limited amount of information that the call requires. Opaque enqueues are not registered. On the other side, the dequeuing process removes the memory handle from the SMQ and examines the flags and operation code in the header. The flags indicate that no information other than the flags and operation code are available. After examining the flags, the dequeuing process calls the appropriate operation code handler.
To assure a response, an item may be registered as part of an enqueue. (Unlike synchronous interprocess communication, outstanding requests are not inherently tracked in an asynchronous interprocess communication environment.) During registration, the memory handle for each item added to an SMQ also is placed on a registration list. At a later time, the registration list can be examined to identify enqueued items that have not received a response, and those outstanding requests may be negatively acknowledged ("NAK'd") so that any needed cleanup operations may be performed. For example, an enqueued item may be dequeued by a remote process. Problems with the remote process, such as the termination of a particular protocol, the abnormal termination of the process itself, etc., may prevent the remote process from responding. When the enqueuing process determines that the remote process is unable to respond, by receiving a protocol or process termination signal or by some other mechanism, each registered enqueue is NAK'd so that resources allocated as part of the enqueue may be reclaimed.
To reduce contention on the registration list, the list is subdivided into sixteen sublists, each with its own lock, so that sixteen separate threads can register/deregister SMQ items or entries at the same time. A hash function determines which of the sublists should receive a particular item. The function divides the lower sixteen bits of a process agnostic memory handle's address pointer into four four-bit sets. Each set of four bits (representing 0-15) are added together and then divided by sixteen. The final remainder is the sublist number (0 to 15). The lock for each sublist is implemented as a critical section.
Note that the foregoing hash function produces perfect distribution across all possible memory allocations. Additionally, it produces perfect sequential distribution, such that 32 allocations of the same sized blocks, that are also sequential in memory, will be perfectly distributed. Blocks allocated in increasing sizes (i.e., 32 bytes, 64 bytes, 128 bytes, . . . ), where each block is in the same state, are perfectly distributed as well. Naturally, once memory becomes fragmented, any two allocations may hash to the same registration list, but overall, the hash function perfectly distributes every set of 16 adjacent blocks.
The pceqB->HrSetThreadThreshold 482 call helps determine if process A 410 should be signaled to create a new worker thread or if the current number of worker threads is adequate. Although making calls to pceqB->HrSetThreadThreshold 482 and pceqB->HrSetThreadThreshold 458 provides some control to the enqueuing process over the number of threads available in the dequeuing processes, the dequeuing process is likely to include its own logic to control the number of threads. In other words, the dequeuing process makes the determination of whether to create a new thread or not, but calling pceqB->HrSetThreadThreshold informs the dequeuing process of the enqueuing process' preference or analysis of the number of threads that should be available. Other processing 486 continues in process B 420 while the enqueue is pending, demonstrating the asynchronous aspect of the present invention.
In process A 410, a notify thread posts to the I/O completion port 488 associated with a particular SMQ. Process A 410 is responsible for determining that the completion key matches a completion key specified in binding the SMQs between process A 410 and process B 420. Calling pceq->IOCPNotification 492 dequeues an item from a particular SMQ, and pceq->Dispatch 494 calls the appropriate handler function. Note that pceq->IOCPNotification 492 and pceq->Dispatch 494 represent a single controller for each SMQ (and protocol). Process A 410 handles the operation code and enqueues a result, as required. Those of skill in the art will recognize that if process A 410 and process B 420 are running on separate processors, no context switches are required between enqueuing and dequeuing items using an SMQ.
FIGS. 7A-7B show an exemplary method of high-performance interprocess communication according to the present invention. Those of skill in the art will recognize that the steps and acts described with reference to FIGS. 7A-7B are not necessarily limited to any particular order. A step for registering (710) one or more handler routines may include the act of dynamically associating (712) handler routines with a dispatch routine and the act of binding (714) a dispatch routine to an SMQ. The registered routines or functions handle the instructions included within an enqueued item—the operation codes stored in memory that are referenced by a process agnostic memory handle. Because the routines may change over time, each side of the communication should check the revision of software running on the other side to assure compatibility.
A step for providing shared memory (720) may include the acts of creating (722) one or more shared memory heaps and creating (724) one or more bi-directional shared memory queues. The shared memory heap may be implemented as one or more shared memory block heaps and a bi-directional shared memory queue may be implemented as a pair of unidirectional circular queues. Other suitable heap and queue arrangements are well-known in the art and should be considered within the scope of the present invention. A step for producing (730) one or more process agnostic memory handles includes the acts of allocating (732) one or more memory regions from the shared memory heaps described above.
A step for enqueuing (740) one or more process agnostic memory handles may include the following acts: placing (742) an instruction in the allocated memory regions; adding (744) the one or more memory handles to the one or more shared memory queues; reserving (746) space for one or more responses; notifying (748) the dequeuing process of the enqueued items; and continuing (752) to execute in the enqueuing process. The present invention is not limited to any particular type of instruction or any particular implementation of process agnostic memory handles. The use of operation codes and the specific memory handle identified with respect to FIG. 5 are merely exemplary.
The act of evaluating (754) the number of memory handles in an SMQ compared to a threshold value relates to the enqueuing process actively considering whether or not the dequeuing process should be signaled to provide one or more additional worker threads. As explained previously, the dequeuing process makes the final determination of whether a new thread is created or not, but this occurs retrospectively in the dequeuing process, after items have been enqueued. Because the enqueuing process knows of items added to an SMQ as the enqueuing occurs, the enqueuing process may be in a somewhat better position to determine whether additional dequeuing threads are needed, either by awakening an idle thread or by creating a new thread.
A step for registering (760) memory handles may include an act of hashing (762) a memory handle to select a particular list from among several registration lists that are available. To avoid contention, the hashing function should evenly distribute memory handles across all registration lists, although the present invention does not necessarily require perfect distribution. The step for registering (760) also may include the act of selecting (764) a registration list and placing (766) one or more memory handles on one or more available registration lists.
A step for dequeuing (770) one or more process agnostic memory handles from one or more SMQs may include the act of posting (772) to a completion port. Dequeuing (770) also may include the acts of creating (774) a new thread or awakening (776) an idle thread. Additionally, removing (778) one or more memory handles from the one or more SMQs and converting (782) the one or more handles to memory addresses may be part of the step for dequeuing (770). Memory address should be interpreted broadly to encompass any form of direct or indirect memory access, including a pointer to a memory location, a reference to a memory location, a handle, etc. The step for dequeuing also may include the acts of using (784) the memory address to retrieve the instruction from the one or more memory handles and dispatching (786) the appropriate handler routines. Although not shown, the step for dequeuing (770) further may include the act of removing one or more memory handles from an available registration list when a response is received. When no response is received, the present invention may include an act of negatively acknowledging (792) a registered memory handle so that resources associated with the memory handle may be reclaimed.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
|Cited Patent
|Filing date
|Publication date
|May 31, 1985
|Jun 2, 1987
|Northern Telecom Limited
|Load balancing for cellular radiotelephone system
|Aug 19, 1991
|Feb 9, 1993
|Sequent Computer Systems, Inc.
|Cache affinity scheduler
|Dec 28, 1992
|Jan 10, 1995
|Starlight Networks
|Data throttling system for a communications network
|Jun 7, 1995
|Aug 6, 1996
|International Business Machines Corporation
|Method and system for optionally registering a local process to allow participation in a single system semantic
|Jun 6, 1995
|Sep 10, 1996
|International Business Machines Corporation
|Method and apparatus for implementing virtual memory having multiple selected page sizes
|Jul 19, 1994
|Feb 25, 1997
|International Business Machines Corporation
|Method and apparatus for distributing control messages between interconnected processing elements by mapping control messages of a shared memory addressable by the receiving processing element
|Nov 3, 1993
|Apr 1, 1997
|Wang Laboratories, Inc.
|Server for executing client operation calls, having a dispatcher, worker tasks, dispatcher shared memory area and worker control block with a task memory for each worker task and dispatcher/worker task semaphore communication
|Oct 8, 1996
|Apr 7, 1998
|International Business Machines Corporation
|Data processing system for sharing instances of objects with multiple processes
|Nov 8, 1996
|Aug 18, 1998
|Compuserve Incorporated
|System for intergrating an on-line service community with a foreign service
|Apr 3, 1995
|Sep 15, 1998
|Digital Equipment Corporation
|High-performance multi-processor having floating point unit
|Jul 11, 1997
|Apr 20, 1999
|Sun Microsystems, Inc.
|Method and system for synchronizing the execution of events
|Dec 18, 1996
|Jun 15, 1999
|Unisys Corporation
|Automatic format conversion system and publishing methodology for multi-user network
|Jun 5, 1996
|Jun 29, 1999
|New Era Of Networks, Inc.
|Method and structure for balanced queue communication between nodes in a distributed computing application
|Aug 23, 1996
|Sep 7, 1999
|Compuware Corporation
|System for memory error checking in an executable
|Citing Patent
|Filing date
|Publication date
|Apr 17, 2003
|Jul 3, 2007
|Slt Logic, Llc
|System and method for providing communications to processes
|Aug 19, 2004
|Dec 11, 2007
|Kabushiki Kaisha Toshiba
|System and method for shared memory based IPC queue template having event based notification
|Mar 26, 2004
|Aug 12, 2008
|Network Equipment Technologies, Inc.
|Method and system for providing registration-based SIP NAT traversal
|Jul 9, 2004
|Oct 7, 2008
|Canon Kabushiki Kaisha
|Inter-program communication apparatus, inter-program communication method, computer-readable recording medium, and program
|Feb 27, 2004
|May 5, 2009
|Rockwell Collins, Inc.
|Joint tactical radio system (JTRS) software computer architecture (SCA) co-processor
|Oct 21, 2003
|Jun 2, 2009
|Gemstone Systems, Inc.
|Shared queues in shared object space
|Jul 22, 2002
|Dec 29, 2009
|Agilent Technologies, Inc.
|System and method for efficiently exchanging data among processes
|Sep 3, 2004
|Jan 26, 2010
|Alcatel-Lucent Usa Inc.
|Implicit interprocess communications (IPC) versioning support
|May 30, 2003
|Jan 26, 2010
|Steven Frank
|Virtual processor methods and apparatus with unified event notification and consumer-producer memory operations
|Oct 21, 2003
|Mar 30, 2010
|Gemstone Systems, Inc.
|Shared listeners in shared object space
|Nov 2, 2007
|Aug 23, 2011
|Vmware, Inc.
|Data replication method
|Oct 26, 2009
|Dec 27, 2011
|Steven J. Frank
|Virtual processor methods and apparatus with unified event notification and consumer-produced memory operations
|Oct 6, 2006
|Apr 17, 2012
|Sony Computer Entertainment, Inc.
|Information processing method and information processing apparatus
|Nov 2, 2007
|May 1, 2012
|Vmware, Inc.
|Object synchronization in shared object space
|Apr 5, 2011
|May 15, 2012
|Vmware, Inc.
|Data replication method
|Nov 2, 2007
|Jun 12, 2012
|Vmware, Inc.
|Object monitoring system in shared object space
|Feb 4, 2010
|Sep 18, 2012
|Steven J. Frank
|General purpose embedded processor
|Dec 14, 2004
|Sep 10, 2013
|Sap Ag
|Fast platform independent inter-process communication
|Nov 14, 2011
|Dec 31, 2013
|Steven J. Frank
|Virtual processor methods and apparatus with unified event notification and consumer-producer memory operations
|Jan 9, 2009
|Feb 4, 2014
|Pivotal Software, Inc.
|Preventing pauses in algorithms requiring pre-image information concerning modifications during data replication
|Aug 30, 2011
|Feb 4, 2014
|Microsoft Corporation
|Efficient secure data marshaling through at least one untrusted intermediate process
|Feb 3, 2014
|Sep 8, 2015
|Pivotal Software, Inc.
|Preventing pauses in algorithms requiring pre-image information concerning modifications during data replication
|Mar 31, 2014
|Nov 17, 2015
|Pivotal Software, Inc.
|Object synchronization in shared object space
|Jul 28, 2015
|Aug 1, 2017
|Pivotal Software, Inc.
|Preventing pauses in algorithms requiring pre-image information concerning modifications during data replication
|Jul 22, 2002
|Jan 22, 2004
|Te-Cheng Shen
|System and method for efficiently exchanging data among processes
|May 30, 2003
|Dec 9, 2004
|Steven Frank
|Virtual processor methods and apparatus with unified event notification and consumer-producer memory operations
|Jul 9, 2004
|Jan 20, 2005
|Canon Kabushiki Kaisha
|Inter-program communication apparatus, inter-program communication method, computer-readable recording medium, and program
|Aug 19, 2004
|Feb 24, 2005
|Sodhi Ajit S.
|System and method for shared memory based IPC queue template having event based notification
|Oct 21, 2003
|Apr 21, 2005
|Monnie David J.
|Shared queues in shared object space
|Oct 21, 2003
|Apr 21, 2005
|Monnie David J.
|Object synchronization in shared object space
|Oct 21, 2003
|Apr 21, 2005
|Monnie David J.
|Object monitoring system in shared object space
|Oct 21, 2003
|May 5, 2005
|Monnie David J.
|Shared listeners in shared object space
|Sep 3, 2004
|Jul 14, 2005
|Sanjiv Doshi
|Implicit interprocess communications (IPC) versioning support
|Dec 14, 2004
|Jun 15, 2006
|Frank Kilian
|Fast platform independent inter-process communication
|Nov 2, 2007
|Mar 13, 2008
|Gemstone Systems, Inc.
|Object monitoring system in shared object space
|Nov 2, 2007
|Mar 20, 2008
|Gemstone Systems, Inc.
|Object synchronization in shared object space
|Dec 13, 2007
|Jul 3, 2008
|Mcclure Steven T
|Bucket based memory allocation
|Apr 2, 2007
|Oct 2, 2008
|Frank Joachim H
|Testing protocol compatability
|Jun 9, 2008
|Dec 4, 2008
|Van Jacobson
|System and method for allocating communications to processors in a multiprocessor system
|Nov 2, 2007
|May 7, 2009
|Gemstone Systems, Inc.
|Data replication method
|Oct 6, 2006
|Mar 11, 2010
|Sony Computer Entertainment Inc.
|Information Processing Method and Information Processing Apparatus
|Oct 26, 2009
|Jun 24, 2010
|Sharp Kabushiki Kaisha Corporation
|Virtual processor methods and apparatus with unified event notification and consumer-produced memory operations
|Jan 9, 2009
|Jul 22, 2010
|Gemstone Systems, Inc.
|Preventing pauses in algorithms requiring pre-image information concerning modifications during data replication
|Feb 4, 2010
|Sep 9, 2010
|Steven Frank
|General purpose embedded processor
|Oct 26, 2009
|Jun 16, 2011
|Steven Frank
|Virtual processor methods and apparatus with unified event notification and consumer-produced memory operations
|Apr 5, 2011
|Jul 28, 2011
|Vmware, Inc.
|Data replication method
|U.S. Classification
|719/312, 711/209
|International Classification
|Cooperative Classification
|European Classification
|Mar 30, 2001
Owner name: MICROSOFT CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CRANSTON, WAYNE M.;YANG, MIN-YU;PURTELL, MICHAEL J.;REEL/FRAME:011671/0928
Effective date: 20010326
|May 23, 2008
|Fee payment
Year of fee payment: 4
|May 9, 2012
|Fee payment
Year of fee payment: 8
|Dec 9, 2014
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034541/0001
Effective date: 20141014
|May 26, 2016
|Fee payment
Year of fee payment: 12


text:
Tipton Nylon Bore Brush 44 Caliber, 3 Pack
Tipton Nylon Bore Brush 44 Caliber, 3 pk. These Nylon Bore Brushes clean while protecting the bore from abrasion.
- Fits: All .44 and .45 Calibers
- Nylon Bristles (.495 Diameter) Unaffected by Ammonia based solvents.
- Galvanized Plated Wire Core with Looped End and Crimped Coupler.
- Thread: Standard 8-32"
- Note: Will Not Fit Outers Cleaning Rods
We Also Recommend

subset: commoncrawl


text:
Appears in all the newspapers on Saturday.
The advertisement in this section can be ordered no later than Friday of the current week by 12 o'clock.
Ad price € 0.01 per character.
Add an image for FREE!
NB! Price include sales tax. Those ads/announcements may only be ordered by private persons.


text:
Looking for a down payment grant? Start here: HomeProgram101.com
Search Results
Listing ID5555062
Listing Price$5,495,000
Total Baths6
Square Feet 8,714
Acres 0.918
You won't be disappointed in this one of a kind Modern Western Farmhouse vernacular designed by architect C.P. Drewett of DrewettWorks. Located in the Nordon Manor Estates this home is a direct...
Listing courtesy of Realty Executives
© 2017 Arizona Regional Multiple Listing Service, All rights reserved. The data relating to real estate for sale on this website comes in part from the Arizona Regional Multiple Listing Service. Real estate listings held by brokerage firms other than The Phoenix Metro Group are marked with the Arizona Regional Multiple Listing Service logo and detailed information about them includes the name of the listing brokers. All information deemed reliable but not guaranteed and should be independently verified. All properties are subject to prior sale, change or withdrawal. Neither listing broker(s) nor The Phoenix Metro Group shall be responsible for any typographical errors, misinformation, misprints and shall be held totally harmless. Listing data last updated Wednesday, August 16th, 2017.
Data services provided by IDX Broker


text:
Portable Visualization of the Inaccessible. Increase Video Inspection Efficiency Through Enhanced Direction of View and lighting.
The KARL STORZ MoVeo™ Videoscope is a fully self-contained professional imaging system. Designed with the user's ergonomics in mind, and your organizations need for efficiency and cost savings. MoVeo™ is available in multiple lengths, outer diameters and interchangeable 0 and 90 degree tips. Digital image capture and video recording are standard features. It is the ideal solution for high-performance automotive and mission critical transport and power generating applications.
- Videoscope Image Sensor: High resolution complementary metal oxide semiconductor
- Compact Integrated Display: 5″ high resolution LCD full RGB color
- Videoscope Diameters: 4mm and 6mm
- Deflection: Precision 4-way articulation
- Locking levers: (2) independent fixation locking levers
- Optional lens: 90° oblique and 0° near-field with safety thread design
- Illumination: Portable LED illuminator included, optional stationary light sources and connectivity available
General Info
MoVeo™ is a new innovative portable ruggedized videoscope system only from KARL STORZ Industrial. This truly mobile videoscope (videoborescope) system is a lightweight ergonomic self-contained hand held visualization and video documentation system. The simple, easy to navigate user interface enables the investigator to navigate simply through MoVeo's intuitive controls all through an integrated 5″ full color LCD display. Lithium ion powered with an integrated high-power LED light source, MoVeo™ is a truly self-contained next generation remote visual inspection tool that can be used remotely for up-to 3 hours.
Embedded software functionality was designed with the professional industrial investigator in mind. Utilizing the signature KARL STORZ user interface experience, special features include archiving and playback of video recording or captured image files. Text annotation can be applied to image files. A unique comparative measurement function enables simple straightforward analysis during inspection processes.
Multifunctional Carrying Case
Remote visual inspection is only the beginning. MoVeo™ offers an industry first, a versatile multifunctional transport case for stationary use. This unique carrying case design is not only ruggedized for today's demanding industrial inspection applications but is also the industry's most ingenious case design as it doubles as a workstation base station. In this application, MoVeo™ can be connected to a mains power supply and supported with it's optional multi-jointed holding arm. This revolutionary case design has ample room to store all of MoVeo's accessories including protective sheaths, interchangeable lenses carrying straps and back-up lithium ion power batteries. An external video output supports ancillary video monitors increasing the stationary inspection performance.
MoVeo™ offers flexibility of sheath diameters and lengths with it's tungsten carbide videoscope design. The user has the option of a videoscope with a sheath of 4mm or 6mm diameter sheath design with working lengths up to 6 meters. All MoVeo™ videoscopes feature a standard integrated lens with a direction of view 0°, field of view 70°, depth of field 15mm to infinity. For application specific needs, all videoscopes are available with a near field and a 90° interchangeable lens with integrated safety thread system.
MoVeo™ Soft Case.
A Carry-on for Your Moveo™ Videoscope. Your Inspection Adventure Awaits.
In addition to our multifunctional case, we offer a multifunctional carrying bag for the MoVeo videoscope as an accessory for applications requiring particular portability. This carrying bag has been especially designed for MoVeo™ users who perform inspections in difficult-to-access areas and don't want to do without important accessories, carrying comfort, and functionality. The bag was designed with safety in mind, and its special materials offer optimal protection for the MoVeo™ videoscope during transport. Thanks to the universal shoulder strap, the bag can also be worn as a backpack.
A Variety of Industrial Products. Multiple Industrial Applications.
KARL STORZ Industrial's collection of products work together seamlessly in a variety of industrial inspection environments. These products provide our customers with the ease of use and image quality they deserve. View the video below to see our products working together in action.


text: Wait List. Rope Dojo is now sold out. The best way now to get into Rope Dojo is by signing up for the Wait ListWhen tickets becomes available you'll be contacted on a first-come-first-serve basis. You will not be charged. Please make sure to leave us your best contact details!


text:
Your MyAtlantis Account
Log In
Online Account Benefits
Terms and Conditions | Privacy Policy | *Must be a Club Paradise member to view your Club Paradise comp points, tier level, and win/loss statements.
Special Offers & Packages
Golf Packages
Tee-off on the most breathtaking golf courses in northern California and northern Nevada.
Bed and Breakfast
Wake up to breakfast for two at our award-winning Toucan Charlie's Buffet &...
AAA Member Discount
Take advantage of great savings and receive your AAA 10% discount off our b...
Hotel Accommodations & Resort Amenities
Bed and Breakfast
Wake up to breakfast for two at our award-winning Toucan Charlie's Buffet & Grille!...
Free Luxury Tower Upgrade
Receive a complimentary room upgrade. Book a Luxury Tower room at an Atlant...
Golf Packages
Tee-off on the most breathtaking golf courses in northern California and no...
Casino Games & Special Events
WPTDeepStacks Summer 2017
WPTDeepstacks at Atlantis Reno takes place August 17 - 28 with a range of buy-ins and guarantee...
Personal Casino Rate Atlantis
It's a win-win! Use the money you save on your rate to enjoy one of our del...
Atlantis Race and Sports Book App
Reno's best book has gone mobile! Enjoy exclusive features available only t...
Dining & Restaurants
Venge Vineyards Winemaker Dinner
Atlantis Steakhouse is proud to present a winemaker dinner featuring Venge Vineyards.
Atlantis Steakhouse
Savor the finest cuts of steaks and chops from a wide-ranging menu of delic...
Spirited Dining Series
Don't miss our exclusive Spirited Dining Series events where we collaborate...
Entertainment & Nightlife
Ultimate X Spin Poker Online Contest
Join our Ultimate X Spin Poker Contest for your chance to win a luxury stay at Atlantis!...
Mayweather vs. McGregor Boxing Viewing Party
Boxing and UFC collide when legendary boxer Floyd Mayweather Jr. takes on t...
Society of Seven
Pure entertainment. Pure fun. That's Society of Seven. Enjoy their original...
Spa & Salon
Spa Packages
Indulge in a spa package to experience the ultimate in relaxation and tranquility.
Atlantis Salon
Get your glamour on right here. Look and feel your best with expert cuts an...
Summer Spa Features
Summer relaxation begins with rejuvenating spa treatments at Spa Atlantis.
Meetings & Conventions
Request a Meetings Proposal
We have designed a program to reward both the business traveler and…...
Corporate Connection
We have designed a program to reward both the business traveler and travel...
Banquets & Catering
Let our professional catering staff take care of all of the details. We off...
Banquets & Catering
Let our professional catering staff take care of all of the details. We offer plated or buffet...
Bistro Napa
Savor contemporary cuisine inspired by Napa Valley in a sophisticated, vibr...
Activities & Reno-Tahoe Community Events
Activities Overview
Book your stay at Atlantis to enjoy year round activities including golfing...
Atlantis Reno resort app
Make reservations, play free games and contests, log in to see your offers.
Atlantis Race & Sports app
Place wagers as low as $1. Bet on the go anywhere in the state of Nevada.
Email Club Sign-up
Join our Email Club to receive special offers, promotions and hot deals!
The priceless Spa experience at Atlantis is the feeling you take home, the renewed optimism, brighter outlook and energy you bring to work, play and people you love.
Going to a spa can help us cope better with stress. Recent survey findings show that spa treatments will help with stress reduction and relief, soothing sore joints and muscles, and simply feeling better.
And at least some studies show that these benefits can translate into better health. In one study of more than 3,300 Japanese government workers, frequency of spa use was linked to better physical and mental health, including better quality sleep and fewer sick days. In a similar study on German data conducted by researchers from Florida State University and George Mason University, spa therapy reduced both absenteeism from work and hospitalizations.
Spa Atlantis is a place for personal rediscovery, solace and healing. It is a refuge from the everyday world. It is a place to restore yourself. Let the healing effects of highly trained aestheticians and massage therapists help you rejuvenate.
Our specialized services can help you relax and decompress. Our spa is centered on wellness from the Aqua Lounge and Experiential Shower to the Laconium Relaxation Room and tea lounge.
Taking time to take care of your body and mind can significantly improve your body image.
Many of our spa services promote detoxification that eliminates toxins and excess fluids that can contribute to loss of energy and water retention. Our Laconium Relaxation Room utilizes gentle heat to purify and detoxify.
Many services, such as heat hydrotherapy massage and body treatments, help to improve circulation and reduce blood pressure.
Taking care of your body, mind and skin helps to ward off the aging process. Treatments, such as facials and other skin care services, as well as body treatments, target skin problems to keep you looking your best.
Many services can help alleviate pain. Some treatments are known to help relieve symptoms of arthritis, fibromyalgia and nerve problems. Our Soft-Pack System® creates a sensation of floating to alleviate pain from pressure points.
Spa: 775.954.4135
Salon: 775.954.4136
Regular Hours
Spa: 8 am – 9 pm
Salon: 8 am – 8 pm
Retail Store: 8 am – 9 pm
Fitness Center: 6 am – 10 pm
Pools: 6 am – 10 pm
Located on the 3rd floor
Virtual Tour
Share this page:
Monarch Black Hawk Careers
Monarch Black Hawk Job Listings
Atlantis Reno App
Make reservations, play free games, log in to view offers, and more! ...Learn More
Atlantis Race & Sports App
Atlantis Sports Book has gone mobile, make your bets here! ...Learn More
About Us |
Maps & Driving Directions |
Press/Media Kit |
Club Paradise |
Green Initiatives |
Atlantis Awards
© 2017 Atlantis Casino Resort Spa. All rights reserved. 3800 S. Virginia St. Reno, NV 89502
Reservations: Toll-free 800.723.6500 or 775.825.4700


text:
Tag: Cyanotype
Having fun on the weekend with Cyanotype is what it's all about. Cyanotype is easy and quick to setup. It was a sunny day in the Steiermark, Austria,…August 1, 2016
Welcome to a very blue weekend of April 23rd 2016. Yes in terms of the downside of the weather with overcast skies and rain with expected snow too – yikes!…April 26, 2016


text:
The new face of Spec Screenplays
|The Script Blogger
|The new face of Spec Screenplays.
Many of you may know about the so called New Style for Spec Screenplays heralded by the formatting guidelines for the PAGE International Screenwriting Award competition.
No don't panic!
Most of the suggestions probably came about because of the number of submissions they received each year that incorporated the new suggestions already.
No doubt included by writers who didn't know better in the first place?
Basically, the major change is the acceptance of BOLD, UNDERSCORE and ITALIC text, but like before, this is not an invitation for a TEXT free–for–all.
The new parameters limit the use of such radical text to Primary Scene Headings, Secondary Scene Headings and Technical Direction. Please note this is not an invitation for Directional Instructions, Camera Movements, Shot Selection or any of the other grey areas amateur writers insist on using.
Technical Direction is information such as SUPER, MONTAGE or FLASHBACK.
The changes are also acceptable for information in the narrative, such as a News Headlines or a Name on a Sign or Building.
Please note there are no suggestions to change the font size or type, Courier 12 is still the accepted face of a screenplay, but a colon is acceptable after a special heading as opposed to a dash.
I doubt if the changes will improve the quality of many screenplays and I can hear the dismay amongst professional readers already, but as with every industry some changes do creep in occasionally and become tradition, as much as the traditions they replace.
Personally I would like to include scene numbers in spec screenplays, simply because when discussing the script over the phone it is easy and quick to identify the scene to discuss.
But as I don't enter the PAGE International Screenwriting Award competition, that wish will probably never happen.


text:
3 pieces of advice how to get dressed for a picnicPosted: October 7th, 2012 | Author: Paul Brown | Fashion
Summer's here. Sunny weather and hot temperatures encourage us to spend time outdoors and make picnics. These occasions require form us to get dressed comfortably. As it's known, each of us wants to look fashionable in any situation. How to get dressed for a picnic in order to look fashionable and feel more comfortable? Here are our suggestions.


text:
PHILADELPHIA Open your 2009 calendars to autumn and prepare to reserve your Saturday afternoons because the University of Pennsylvania has announced its football schedule for the upcoming season. The 2009 season, the team's 133rd at Penn, will pit the Quakers against their familiar Ancient Eight foes as well as Bucknell, Lafayette and renewed-rival Villanova. Homecoming is set for Nov. 7 against Princeton.
Similar to last season, Penn will begin the quest for their 14th Ivy League title against Villanova at Franklin Field on Sept. 19 in a rematch of last year's overtime thriller. The Quakers then travel to Easton, Pa., to face off against Lafayette.
After battling against local Pennsylvania teams the first two weeks, Penn will kick off the Ivy League season when they journey to Hanover, N.H., to take on the Dartmouth Big Green. The Quakers will then return home to play Bucknell on Oct. 10 in their last non-conference game of the season.
Penn heads to the Big Apple on Oct. 17 to play Columbia before hosting Yale on Oct. 24 on Family Weekend.
Halloween begins what looks to be a particularly key stretch for the Quakers. On Oct. 31, Penn voyages to Providence, R.I., to battle the defending Ivy League co-champion Brown Bears. A week later, the Homecoming game will have a familiar flavor as Penn will play host to archrival Princeton. The schools will be facing off against each other for the 101st time. On Nov. 14, the Quakers will take on the other defending Ivy co-champion, Harvard, in Cambridge, Mass.
Penn closes out the season at home on Nov. 21 with one of the oldest matchups in NCAA historythe 116th meetingbetween the Quakers and Cornell Big Red.
Game times and radio and television dates will be announced at a later date.
Penn 2009 Dates and Opponents
Sept. 19 VILLANOVA
Sept. 26 at Lafayette
Oct. 3 at Dartmouth
Oct. 10 BUCKNELL
Oct. 17 at Columbia
Oct. 24 YALE (Family Weekend)
Oct. 31 at Brown
Nov. 7 PRINCETON (Homecoming)
Nov. 14 at Harvard
Nov. 21 - CORNELL
Home games in CAPS.


text:
Azoff MSG-AEG Feud Could Be Near End Mercedes-Benz Stadium To Showcase Atlanta Culture SDSU Still Working On Possible Stadium Deal Pelicans Submit NBA G League Facility Proposal Man City Unveils Exclusive Tunnel Club Membership Mercedes-Benz Stadium's Roof Still Not Ready 49ers Hope Levi's Stadium Feels More Like Home Officials Honing In On Site For New Rays Park SunTrust Park's Financial Effects Become Clearer Facility Notes
Upcoming Conferences and Events
SBD/July 13, 2011/Facilities
Facility Notes
Published July 13, 2011
SAFETY FIRST: MLB Rangers Exec VP/Communications John Blake said team execs started face-to-face meetings with industry officials yesterday to determine "whether to raise railings or do whatever might be appropriate for the safety of our fans." Blake said that team officials "called contractors, architects and other experts familiar" with the 17-year-old Rangers Ballpark last week after fan Shannon Stone fell to his death (DALLASNEWS.com, 7/12).
STOP, DROP & ROLL: The GUARDIAN's Owen Gibson reports U.K. Minister of Sport Hugh Robertson has urged EPL club Tottenham Hotspur to "abandon legal action over the future of the Olympic Stadium, warning that London's bid to host the 2017 World Athletics Championships will be dead in the water unless the matter can be resolved soon." Robertson said that "unless the future of the stadium, awarded to West Ham by the Olympic Park Legacy Company but the subject of an ongoing legal challenge from Spurs, was decided by 1 September then the bid would have to be withdrawn." He added, "I would hope Tottenham would see the greater good to London" (GUARDIAN, 7/13).
COMING FULL CIRCLE: In K.C., Kevin Collison reports 360 Architecture "has won another big sports facility design contract in Iraq, this time for two soccer stadiums with a total value" of $170M. The K.C.-based firm "will be teaming with Anwar Soura General Contracting Co." on the projects. 360 Senior Principal George Heinlein said that the new commissions "were the result of the firm's experience" designing a complex in the Basra, Iraq, that includes a 65,000-seat soccer stadium. That project is "about two-thirds complete" (K.C. STAR, 7/13).


text:
Robert Max (via empathic mimicry)
Peter Petrelli World 8 (via empathic mimicry)
Jessica Petrelli (via empathic mimicry)Anna Matthews
Electric impulse manipulation is the ability to manipulate electrical impulses within the body.
- Lily Bishop has this ability naturally.
- Jacob Bishop also has this ability naturally, like his twin.
- Robert Max has gained this ability through empathic mimicry.
- In World 8, Peter Petrelli has also absorbed the ability.
- Jessica Sky Petrelli has also absorbed the ability.
- Anna Matthews also has this ability naturally.
Lily Bishop
Lily possesses the ability to manipulate electrical impulses within the body, like her brother. Using it, she can control the conscious mind and people's thoughts through a touch, She has also been shown using the ability to kill by blocking the heart's contractions. Where Lily seems to excel at is in controlling physical movement without touch, by manipulating motor neurons from a distance with the ability. This gives her control over a person's physical movement, thus making them vulnerable. Additionally, Lily has used the ability to manipulate nerves that carry electrical impulses to induce great pain into her victims through touch, as well as blocking access to an evolved human's ability.
Jacob Bishop
Jacob too is able to control electrical impulses within the body, meaning he is able to manipulate thoughts and consciousness. He too is able to kill his victims by blocking their heart contractions. Jacob has been shown controlling the brain through electrical impulses and creating intense pain in people's nerves. He seems to be able to use this ability with great control and can create electro-mental ignitions which reveal a person's memories, even killing by showing the victim all their bad memories within a flash. An explanation for both Lily and Jacob having this ability may be because of his mother's similar ability to manipulate electricity.
Robert Max
Robert has mimicked the ability from the both of his children and therefore has the same limits as the pair.
Peter Petrelli
Peter has similar limits to Robert, but is yet to use the ability.
Jessica Sky Petrelli
Jessica has the same limits too. She has used the ability once to knock a person unconscious with a touch.
Anna Matthews
To date, Anna has shown that she can alter a person's thoughts and perceptions when she has prolonged skin contact with them, by manipulating the electrical impulses within their brains and sensory neurones. She can also control movement by manipulating motor neurones, but finds it easier to do so using her movement manipulation. She will eventually learn to block the use of abilities with contact, but this will be the hardest aspect of the ability for her. She will never have any interest in even learning how to kill or render a person unconscious with her ability.
Similar Abilities
- Neurocognitive deficit can close down the upper brain functions of a person
- Neuronal vampirism is the ability to withdraw energy from nerve impulses and gain strength from it
- Electrokinesis is the ability to create and manipulate electricity
- Puppetry is the ability to control people's motor functions
- Memory manipulation can manipulate the memories of others
- Mental manipulation can manipulate the upper brain functions of a person
- Ability negation and ability negativity can block people's abilities
- Nervous system manipulation is the ability to manipulate a person's nervous system
- Nerve manipulation is the ability to manipulate the nerves of others
- Nocikinesis is the ability to manipulate pain
- Pain inducing is the ability to force others to feel pain
- Paralysis touch is the ability to paralyse others with a touch
- Narcosis is the ability to numb bodily sensations


text:
The Rusty Relic is a sword that can be used in Legendary Swords, it is the first sword you obtain in the mini-quest.
The Rusty Relic is found stuck in a rock within a cave. You must pull it out and use it to fend off the robot bats.
The Rusty Relic seems to be a badly chipped, bronze sword with a black hilt. Some artwork of the Rusty Relic also depicts what appears to be a ruby embedded in the hilt.
- The Rusty Relic bears a striking resemblance to Finn's Golden Sword from the TV series Adventure Time.
- The fact that the Rusty Relic is embedded in the stone and that you must pull it out is a direct reference to the legend of King Arthur.


text:
High Flyers
Text Here
Latest Photos...
15th Jun 2017
These P1, P2 and P3 children have been working hard in class this week! Well done!
1st Jun 2017
These children have been working hard in class and received High Flyer certificates....
25th May 2017
Well done to all these boys and girls who have been working really hard over the...
6th May 2017
These boys and girls were awarded our high flyer certificates this week. Well done!
27th Apr 2017
These children have been working hard during the first week back after the holidays!...
6th Apr 2017
These children have worked really hard in class this week. Well done!
Carniny Primary School, 61 Old Cullybackey Road, Ballymena Co. Antrim BT43 5JR Email: email@example.com | Phone: 028 25643814
WEBSITE BY: SCHOOLWEBDESIGN.NET | Login


text:
nuevas TRENZAS informs
june 2013 N° 11
Financial Inclusion of Young Rural Women. A Balance of Public Policies and Development Programs Mariana Paredes Marulanda Consultores Nuevas Trenzas is a regional program that focuses in generating new knowledge about young rural women for designing efficient public policies and development programs. Generating and disseminating specialized knowledge about Latin American young rural women as a collective, their characteristics and expectations, as well as about public policies and development programs that focus on them are among the program's objectives. In that sense, this study looks to put forward a general outlook of development programs and public policies aiming at promoting and enhancing financial inclusion of young rural women in Latin American, highlighting the importance of financial inclusion as a tool for promoting strategies for reducing poverty and vulnerability. Financial inclusion implies achieving the access and use of a wide range of integral financial services (savings, credit, insurance, payments, transfers) including developingabilities aiming at promoting the correct use of financial services and informed decision making regarding this topic. Achieving greater financial inclusion is anincreasing concern for countries throughout due to its effect over poverty eradication strategies. Main trends in the identified policies and programs For carrying out a critical revision of public policies and development programs focusing in enhancing young rural women's financial inclusion, even whendoing so only partly or indirectly, available information about financial inclusion programs and public policies related to this collective in Latin America and the Caribbean (LAC) was reviewed. The identified programs all have in common their focus on supporting poor and low income families from rural and urban areas. While many programs have a nationwide scope, in many countries poverty is often more severe in the rural areas furthest away from urban centers, which explains why many programs end up focusing in rural areas. On the other hand, Conditional Cash Transfer Programs (CCT programs) direct their interventions towards poor families, particularly the mother, which makes these programs also pertinent for analyzing financial inclusion and rural women programs. Generally, for focalization purposes, most programs aiming at the reduction of poverty use Conditional Cash Transfers (CCTs) as instruments. In these cases, even if the program's objective is not financial inclusion per se, they do impact financial inclusion given their mechanisms for paying the CCTs use the financial system. On the other hand, a range of programs has been identified whose main objectives are promoting savings, credit or micro-insurance, always emphasizing the importance of these tools for contributing to reduce poverty and vulnerability. Taking into account the identified objectives, the programs may be classified in:
Page 1
• Conditional Cash Transfers Programs (CCTs), whose objective is reducing poverty and vulnerability. • Programs whose objective is granting access to one or several financial products. • Programs whose objective is generating financial and economic abilities. On the other side, it is acknowledged that financial services seek to promote the identified programs themselves, as well as the payment channels used for the incentives or CCTs, depending on the program's approach. For paying the cash transfers, most CCT programs deposit the money in a savings account, which has no doubt brought families closer to the financial system, specially the mothers as they are the recipients of the family transfers. CCT programs focus generally in complementing poor the income of poor household in order to prevent them from falling into deeper levels of poverty. In this sense, many programs encourage the spending of the resources the families receive, which at first glance it is perceived as contradicting the promotion of savings. In many cases, it has been found that financial inclusion of young rural women is not part of the identified programs' specific objectives. This has caused a waste of efficacy of the strategies fostered for promoting this collective's financial inclusion, as well as poverty reduction. However, linking CCT programs to financial inclusion initiatives has had an important effect in bringing motherscloser to the financial sector, which is in itself a noteworthy result, specially from NuevasTrenzas' perspective. Also, the characteristics of poverty in the region's countries, which is more severe in rural areas, and the participation of young mothers in receiving CCTs motivate us to believe that it is precisely these programs that may entail better results regarding this collective's financial inclusion. CLOSING CONSIDERATIONS From the collective of young rural women The importance of financial inclusion in national strategies for struggling against poverty is, no doubt,a compensatory tool for buffering adverse shocks. Recent progress in financial inclusion processescall for the improvement of the financial system's capillarity for penetrating in rural areas and areas far from urban centers by means of very light channels such as cell phones. Concerns arising in relation to the arrival of these systems to rural areas regard the ability of the population for using these technologies. Nevertheless, it is necessary to have more information for determining the effect of financial inclusion processes among the collective of young rural women caused by programs such as the ones described in this document. Given that those programs have do not aim solely at this group and their results are not disaggregated, it is important to look deeper into the potential impact on the poor rural population benefiting from the access and use of the financial system promotion programs channeled through young women. On the other hand, until now, the results of somefinancial inclusion programs may be seen in the improvement of beneficiaries' self-esteem and empowerment, indicating that financial inclusion can be a powerful tool for contributing (along with other instruments) to thwart gender gaps and traps that young rural women face. In particular, the access and use of financial services by this collective could counterbalance the disadvantage in the access to productive assets, given that they would have their own assets, allowingthe reduction of dependency and the increase of their importance in the process of decision making in the family, especially regarding those related to investment, expenses and consumption.
Page 2
From the national level In most of the region's countries, the challenges for financial inclusion arise from the characteristics of the excluded population that presents, in general, the lowest income and resides in the most remote areas or inperi-urban areas. One of the basic requirements for financial inclusion is the implementation of specific norms of supervision that seek to protect the financial consumer and regulate the operations of financial products aimed at the low income population. Another limitation that must betackled is the financial system's lack of appropriatecoverage that ends up restraining the scope of financial inclusion programs directedat the low income population, even more so for the case of rural populations. In effect, the natural development of financial systems has led them to concentrate their distribution channels in the most populated areas in the measure that most of the financial activity is centralized there. This has resulted in a lack of attention towards the most remote areas that, from the point of view of social policy and economic development, end up having no access to the right tools for managing their lives and businesses. Given the absence of public policies aiming at dealing withthe financial system's lack of coverage in terms of infrastructure, social and CCT programs face the challenge of channeling payments at the lowest possible cost. The analyzed CCT programs illustrate the difficulties for making payments due to the lack of distribution channels, which ends up limiting the effects of the financial inclusion expected to achieve through this medium. Another aspect to take into account is the type of distribution channels, of financial services, that is really sustainable in very remote areas with low population density. When considering this issue, electronic channels emerge as the most suitable solution in the measure that they allow reaching the most remote areas. However, in every case, it is required in every case to take on significant public policy issues such as communications infrastructure and models of mobile banking in which mobile telephony providers and financial services providers are both able to participate. Finally, the need for re-thinking the strategies for preparing the demand based on financial inclusion has been pointed out. Many countries and programs have already made significant efforts for developing financial education programs but there are still many challenges to overcome. One of them concerns the suitability of dissemination channels for making the efforts more sustainable and thus reaching more low income population.
Page 3
To access the full Spanish version of this document go to Nuevas Trenza's website.
www.nuevastrenzas.org Nuevas Trenzas is possible thanks to the financial support of:
Page 4


text:
|» Products
|» Farali Chiwda
|» Snack Bowlz
Snack Bowlz
Product Code : SB-22
Brand Name : KHUSH EXPORTS
Price And Quantity
- Unit of Measure
- Piece/Pieces
- Minimum Order Quantity
Trade Information
- Payment Terms
- Cash Advance (CA), Cash in Advance (CID), Cheque
- Supply Ability
- Depends On Order
- Delivery Time
- Days
- Main Export Market(s)
- Asia, Australia, Central America, North America, South America, Eastern Europe, Western Europe, Middle East, Africa
- Main Domestic Market
- All India
Product Description
Being a quality conscious entity, we are bringing forth fresh and quality approved Bowlz. The offered range is highly demanded by the kids owing to its delectable taste and healthy attributes. The offered range of Bowlz is processed at vendor's well equipped unit making use of quality tested ingredients under hygienic environment conditions. In order to ensure its safe use and quality, the team of experts tests the offered range against numerous quality parameters and industry standards. Moreover, it is packed in attractive packaging materials.
- Hygienically processed
- Used natural and healthy ingredients
- Safe consumption
- Rich in taste and nutritional values
Nr. Tejendra Prasad Bunglows, Memnagar, Ahmedabad - 380052, Gujarat, India
Phone :+918898086303
Mr. Anil N Patel (Proprietor)
Mobile :+918898086303
Accepts only Export inquiries Send Inquiry


text:
Find storage near you
- Reserve now, pay later.
- Cancel for free, anytime.
Loveland, CO Self Storage
Verified Information SpareFoot provides the most accurate real-time information for every storage unit and facility.
This information was last updated 10 days ago
View All Units »
Self Storage at Centerra
5225 East 37th Street Loveland CO 80538
4.4 miles away
SpareFoot last checked this information 33 minutes ago
View All Units »
Waterglen Self Storage
1202 Waterglen Drive Fort Collins CO 80524
14.6 miles away
This information was last updated 2 days ago
View All Units »
NoCo Storage
4973 Goodman Road Timnath CO 80547
10.2 miles away
Secure Space Self Storage - Mulberry
3115 East Mulberry Street Fort Collins CO 80524
12.9 miles away
This information was last updated 9 days ago
View All Units »
Can't decide? Let SpareFoot help you choose!1 (877) 691-2491
Out of network facilities
Average Price of Storage in Loveland
The biggest factor when it comes to storage unit pricing in Loveland is size. Below are some montly price ranges you can expect to see in Loveland based on different storage unit sizes.
|Unit Size
|Average Price
|Lowest Price
|5 x 5
|5 x 10
|10 x 10
|10 x 15
|10 x 20
The overall average price of a storage unit in Loveland is $87.
Loveland Storage: At A Glance
How does seasonality affect Loveland storage prices?
Storage prices in Loveland tend to be somewhat volatile when compared to other cities. Prices can vary by about 68.42 monthly depending on the time of year. Loveland storage prices are highest in December, and lowest in November.


text:
Deevaan Villa Development (GNIS FID: 1263422) is a populated place located within the Township of Ordway, a minor civil division (MCD) of Brown County.
The elevation of Deevaan Villa Development is 1,299 feet. Deevaan Villa Development appears on the Ordway U.S. Geological Survey Map. Brown County is in the Central Time Zone (UTC -6 hours).
Brown County: Subdivisions (MCDs) | Cities & Towns | ZIP Codes | Features (airports, churches, hospitals, etc.)
BIG Map |
Driving Directions |
Data Source - USGS GNIS FID: 1263422
BOUNDARY MAPS: Township of Ordway | Brown County
Aberdeen, SD
(3.1 miles SSW)
Bath, SD (7 miles ESE)
Bath Corner, SD (7 miles ESE)
Westport, SD (10.1 miles N)
Columbia, SD
(10.2 miles NE)
Warner, SD (12.5 miles S)
Stratford, SD (15 miles SSE)
Prairie Wood Village Addition, SD
(1.4 miles ENE)
Gederos Estates, SD (2.7 miles WNW)
Fisher Estates, SD (3.1 miles WNW)
Harlin Addition, SD (3.4 miles WSW)
Country Village Mobile Park, SD
(3.4 miles W)
Melrose Addition, SD (3.6 miles S)
Richfield Heights, SD (3.9 miles W)