当前位置:文档之家› RTCAST Lightweight Multicast for Real-Time Process Groups

RTCAST Lightweight Multicast for Real-Time Process Groups

RTCAST Lightweight Multicast for Real-Time Process Groups
RTCAST Lightweight Multicast for Real-Time Process Groups

RTCAST:Lightweight Multicast for Real-Time Process Groups Tarek Abdelzaher,Anees Shaikh,Farnam Jahanian,and Kang Shin

Real-time Computing Laboratory

Department of Electrical Engineering and Computer Science

The University of Michigan

Ann Arbor,Michigan48109–2122

zaher,ashaikh,farnam,kgshin@https://www.doczj.com/doc/d314947333.html,

Abstract

We propose a lightweight fault-tolerant multicast and mem-

bership service for real-time process groups which may ex-

change periodic and aperiodic messages.The service sup-

ports bounded-time message transport,atomicity,and order

for multicasts within a group of communicating processes

in the presence of processor crashes and communication

failures.It guarantees agreement on membership among

the communicating processors,and ensures that member-

ship changes(e.g.,resulting from processor joins or depar-

tures)are atomic and ordered with respect to multicast mes-

sages.We provide the?exibility of an event-triggered ap-

proach with the fast message delivery time of time-triggered

protocols,such as TTP[13],where messages are deliv-

ered to the application immediately upon reception.This is

achieved without compromising agreement,order and atom-

icity properties.In addition to the design and details of the

algorithm,we describe our implementation of the protocol

using the-Kernel protocol architecture running under RT

Mach3.0.

1.Introduction

Process groups are a widely-studied paradigm for design-

ing dependable distributed systems in both asynchronous

[6,3,19,15]and synchronous[13,4,11]environments.In

this approach,a distributed system is structured as a group of

cooperating processes which provide service to the applica-

tion.A process group may be used,for example,to provide

active replication of system state or to rapidly disseminate

information from an application to a collection of processes.

Figure1.A general framework for a middle-

ware group communication service

posed protocol as part of a larger suite of middleware group communication services that form a composable architec-ture for the development of embedded real-time applica-tions.Shaded blocks in Figure1indicate those services whose design and implementation we present in this paper. These services consist of two major components,a timed atomic multicast,and a group membership service.They are tightly coupled and thus considered a single service,re-ferred to as RTCast in the remainder of the paper.Clock syn-chronization is assumed in the protocol and enforced by the clock synchronization service.To support portability,RT-Cast might lie atop a layer exporting an abstraction termed a virtual network interface.Ideally,this interface would trans-parently handle different network topologies,each having different connectivity and timing or bandwidth character-istics.The network is assumed to support unreliable uni-cast.Finally,the top layer provides functional(API)support for the real-time process group service and interfaces to the lower RTCast protocol.

RTCast proceeds as senders in a logical ring take turns in multicasting messages over the network.A processor’s turn comes when the logical token arrives,or when it times out waiting for it.After its last message,each sender multicasts a heartbeat that is used for crash detection.The heartbeat received from an immediate predecessor also serves as the logical token.Destinations detect missed messages using sequence numbers and when a processore detects a receive omission,it crashes.Each processor,when its turn comes, checks for missing heartbeats and eliminates the crashed members,if any,from group membership by multicasting a membership change message.

A key attribute of RTCast is that processes which detect receive omissions take themselves out of the group.This paper argues that in a real-time system bounded message transmission time must be achieved.If a message(or its re-transmission)does not reach a destination within a speci?ed time bound,the destination fails to meet its deadline(s)and should be eliminated from the group.

In the next section we discuss the related work on fault-tolerant multicast and group membership protocols.Sec-tions3and4present our system model and the design of the RTCast protocol,respectively.Real-time schedulabil-ity and admission control are described in Section5.Sec-tion6discusses the current implementation of the protocol in the x-Kernel protocol development environment and our PC-based development testbed.Section7concludes the pa-per by discussing the limitations of this work and future re-search directions.

2Related work

Several fault-tolerant,atomic ordered multicast and mem-bership protocols have been proposed for use in asyn-chronous distributed systems.In some of the earliest work, Chang and Maxemchuk[7]proposed a token based algo-rithm for a process group where each member sends its mes-sages to a token site which orders the messages and broad-casts acknowledgments.Destinations use the acknowledg-ments to order messages as speci?ed by the token site. Though the algorithm provides good performance at low loads,acknowledging each message before sending the next increases latency at higher loads.Moreover,introducing a third node(the token site)in the path of every message makes the service less available.Failure of the token site will delay message reception even if both the source and destination are operational.In contrast,RTCast does not ac-knowledge each message,and need not involve an interme-diate node on the path of each message.

ISIS[5,6]introduced the concept of virtual synchrony, and integrated a membership protocol into the multicast communication subsystem,whereby membership changes take place in response to communication failure.ISIS im-plements an atomic ordered multicast on top of a vector clock-based[14]causal multicast service,using an idea sim-ilar to that of Chang and Maxemchuk.While we integrate membership and multicast services,we implement ordered atomic multicast directly without constructing a partial or-der?rst.The ordering task,however,is simpli?ed by as-suming a ring network.In addition to ISIS,several other systems have adopted the notion of fault-tolerant process groups,using similar abstractions to support distributed ap-plications.Some of these include Consul[15],Transis[3], and Horus[19].

The Strong Group Membership protocol[12]performs atomic ordered group membership changes using a two phase commit protocol whereby a leader?rst multicasts a prepare to commit message,and then multicasts a commit message to install the change after receiving acknowledg-

ments.The MGS protocol[18]for processor group mem-bership uses three phases:the?rst to request/acquire a lock (by the group leader)on the membership state table of each member,the next to send new data and collect acknowledg-ments,and the third to retransmit changes to processors from which acknowledgments are missing.Additional work on group membership protocols appears in[2,10,17].

Common to the above mentioned protocols is that they do not explicitly consider the needs of hard real-time appli-cations.Thus these techniques are not suitable for the ap-plications in which we are interested.There are,however, several protocols that target real-time applications.

Totem[4]is an example of a protocol that provides prob-abilisticreal-time guarantees.It is based on a token ring,and guarantees atomic ordered delivery of messages within two token rounds(in the absence of message loss).RTCast,on the other hand,achieves atomicity and order within a single round.Messages are delivered to the application as soon as they are received in order without the need for acknowledg-ments.If one of the processors fails to receive a message and a retransmission request is issued,message delivery will be delayed only on that processor;the remaining ones can deliver immediately upon reception.The intuitive reason why immediate delivery does not interfere with atomicity in RTCast is that processors failing to receive a message take themselves out of the group.

Rajkumar et.al.[16]present an elegant pub-lisher/subscriber model for distributed real-time systems. It provides a simple user interface for publishing messages on a logical“channel”,and for subscribing to selected channels as needed by each application.In the absence of faults each message sent by a publisher on a channel should be received by all subscribers.The abstraction hides a portable,analyzable,scalable and ef?cient mechanism for group communication.It does not,however,attempt to guarantee atomicity and order in the presence of failures, which may compromise consistency.

TTP[13]is similar to RTCast in many respects.It uses a time-triggered scheme to provide predictable im-mediate message delivery,membership service,and redun-dancy management in fault-tolerant real-time systems.Un-like TTP,however,we gain?exibility by following an event triggered approach,where the complete event schedule need not be known a priori,and individual events may or may not be triggered by the progression of time.Moreover,while the design of TTP is simpli?ed by assuming that messages sent are either received by all correct destinations or no destina-tion at all(which is reasonable for the redundant bus LAN used in TTP).We also consider the case where a sent mes-sage is received by a proper subset of correct destinations, which might occur in the case of receiver buffer over?ow, or message corruption on one of many links in an arbitrary topology network.

Finally,a research effort complementary to ours is re-ported in[8].While we consider fault tolerance with respect to processor failure,we do not suggest a mechanism for im-plementing fault-tolerant message communication.For ex-ample,we do not specify whether or not redundancy is used to tolerate link failures.On the other hand,Chen et.al.de-scribe a combination of off-line and on-line analysis where spatial redundancy,temporal redundancy,or a combination of both,may be used to guarantee message deadlines of pe-riodic message streams on a ring-based network in the pres-ence of a number of link faults as speci?ed for each stream. Unless the fault hypothesis is violated,the mechanism guar-antees that at least one non-failed link will always be avail-able for each message from its source to all destinations. 3.System model and assumptions

We consider a distributed system in which an ordered set of processing nodes are or-ganized into a logical ring representing a single multicast group.Each node runs a deamon process responsible for multicast communication.The ring is assumed to have the following properties.

P1:Each processor on the ring has a unique processor-id.

P2:For any two processors,,,there exists a(logi-cal)FIFO channel from to along which

can send messages to(i.e.,the network is not parti-tioned).

P3:Message delays along a channel are bounded by some known constant unless a failure occurs.That is, any message sent along channel is either received within or not received at all.

P4:Processor clocks are synchronized.

An illustration of the ring is shown in Figure2.Note that to-tal order of messages is trivially achieved because channels are FIFO,processors(senders)are ordered,and communi-cation delay is bounded.All messages,unless they are lost, are received by each processor in the order they were sent. Thus,in the remainder of this paper we shall assume that if message was received before message then was sent before.

The assumed failure semantics are as follows.

A1:Processors fail by crashing,in which case the processor halts and its failure is detectable.Send omissions are converted to crash failures by halting a processor if it does not receive its own message.

A2:Message receive omissions are allowed,e.g.,when messages are lost due to transient link failures,or are discarded by the receiver,due to corruption or re-ceiver’s buffer over?ow.Permanent link failures(re-sulting in network partitions)are not considered.We

Shows the order of senders on the logical ring.

Traces the flow of some multicast message m1.of token rotation. showing direction The logical ring

The token

Figure2.The logical ring

believe that the proper way to handle permanent link failures in fault-tolerant real-time systems is to employ hardware redundancy,for example,as in TTP[13]or suggested in[8].

4.Multicast and membership service

Our primary purpose is to provide a multicast service for dis-tributed real-time systems that achieves atomicity and total ordering on messages.The latter is trivially achieved under assumptions P1–P3.Thus,our main concern is to ensure the former,namely multicast atomicity,so that“correct”members can reach an agreement on replicated state.We formulate the problem as one of group membership.Quite simply,a processor that detects a message receive omission takes itself out of the group,thus maintaining agreement among the remaining ones.Each receiver may thus deliver each message immediately upon receipt,yet be guaranteed that delivery is atomic since processors which missed that message will leave the group.In a real-time system one may argue that processes waiting for a message that doesn’t arrive will miss their deadlines anyway,so it is acceptable to eliminate the processor(s)which suffered receive omis-sions.1

Membership changes are communicated exclusively by membership change messages using our multicast mecha-nism.Since message multicast is atomic and ordered,so are the membership changes.This guarantees agreement

reception

ack

14if need more join

acks

16else state=RUNNING

end

Figure3.Message reception handler

on membership view.Order,atomicity and agreement are proved more formally in[1].

Section4.1presents the steady state operation of the al-gorithm(with no receive omissions,processor crashes or membership changes).Section4.2then describes how re-ceive omissions are detected and handled.Section4.3de-scribes processor crashes and member elimination.Sec-tions4.4and4.5discuss other membership changes(joins and leaves),and the relevant issue of recomputing token ro-tation time.Finally,Section4.6extends the design to man-age message retransmissions.

The protocol is triggered by two different event types, namely message reception,and token reception(or timeout). It is structured as two event handlers,one for each event type.The message reception handler(see Figure3)detects receive omissions as described in Section4.2,delivers mes-sages to the application,and services protocol control mes-sages.The token handler(Figure4)is invoked when the token is received or when the token timeout expires.It de-tects processor crashes as described in Section4.3and sends messages out as described in Section4.1.

4.1.Steady state operation

We employ a logical token ring algorithm to control access to the communication medium.Upon receipt of the token, a processor multicasts its messages starting with a member-ship change message,if any membership changes were de-tected during the last round.As messages are sent they are

token

2Rollover is not a problem.Message number0follows in order the mes-sage with the maximum assignable number.Since message communication time is bounded,“old”messages do not survive to be confused with newer ones having the same number.

3Expression1will be re?ned in Section 4.4as new factors are considered 4.2.Message reception and receive omissions

Each processor maintains a message sequence vector,, which holds the sequence number of the last message re-ceived from every group member(including itself)4.Let

be the number of the last message received from processor .The multicast protocol layer expects to receive multi-cast messages in total order.Thus,after receiving message number,the receiver expects message number

from or,if was marked,the receiver expects message number from processor.is the successor of in the current group membership view. If the next message received,say,is not the expected message,a receive omission is detected,and the receiver should crash.

As an optimization,we prevent receivers crashing upon detectably“false”receive omissions.Instead of having it crash,we?rst check whether or not the presently received message is a membership change message which elimi-nates the sender,say,of the missed message from mem-bership5.If so,also contains the number of’s last message sent before it was eliminated.This number is at-tached by the sender of the membership change message ac-cording to its own message vector information.If this num-ber matches in the current receiver’s message sequence vector then the receiver is assured that all messages sent by before it was eliminated have been received,and hence the receiver remains in the group.Otherwise,the receiver concludes that it did suffer a receive omission and it crashes.

4.3.Membership change due to processor crashes

Each processor keeps track of all other group members from which it has received a heartbeat during the current token round.That is,it records the processors from which it received a heartbeat since the time it sent its own and until it either receives that of its predecessor or times out, whichever comes?rst.Either case indicates that’s turn to send messages has come.

When’s turn comes,it?rst determines the processors from which it has not received a heartbeat within the last to-ken round.A possible decision then is to assume that all of them have crashed and eliminate them from group member-ship(by multicasting a corresponding membership change message).It turns out,a better decision is to eliminate only the transitive closure of immediate predecessors from which a heartbeat has not been received,if any.The rationale for this is best illustrated by an example.Consider Figure5

Figure5.Excluding failed members. where processor has just timed out.Assume that de-termines that it has not received a heartbeat from processors ,,and.In this case should eliminate only and .is not eliminated since it would have been eliminated by had it indeed been down.If has not eliminated, then it must have received a heartbeat from it,and must be alive,even though its heartbeat did not reach.

Note that this algorithm does not distinguish between to-ken loss and processor failure.Thus,a correct processor may occasionally be eliminated from the group.If a proces-sor receives a membership message telling it that it has been eliminated from the group it crashes.

4.4.Membership change due to joins and leaves

In the previous section we described how processors sus-pected of having crashed are eliminated from the group.The remaining membership changes are voluntary member joins and member departures.A member can leave the group simply by multicasting a membership change message elim-inating itself from membership.When a new processor, ,wants to join a group it starts out in a joining state where it sends a join request message to some processor in the group,which may later multicast a membership change message on behalf of the joining processor,adding it to the group.The message is received atomically by mem-bers of the group who then send acknowledgments to the joining processor,containing their current membership view (with the new member added).The joining processor,now considered a member,checks that all received acknowledg-ments(membership views)are identical,and that acknowl-edgments have been received from every member in that view.If the check fails the new member crashes and at-tempts to rejoin later.

Note that,before joining,the new processor does not have an assigned slot on the ring.On a multiple access LAN this causes a problem since any access to the communication meduim has to be charged to a slot assigned to some proces-sor in the group in order to preserve bounded token rotation time.6To address this problem in our broadcast LAN imple-mentation,the group contains a join slot,,large enough for sending a join message.Expression1,which gives the maximum token rotation time is thus re?ned to include

the processor with the smallest id among those in the current membership.Note that since processors agree on current membership,they also agree on who runs the reclaimer.The module detects if any balance remained unuti-lized for more than a certain amount of time,after which it multicasts a request to reduce by the corresponding bal-ance.

4.6.Handling retransmissions

We mentioned earlier that a communication layer below the multicast and membership protocol,,may be re-sponsible for(transparent)message retransmission.Let us call it the layer.During normal operation this layer simply forwards all messages up to in received order.However,if a message is detected missing it queues up an outgoing retransmission request and tem-porarily holds all subsequent incoming messages.If a re-transmission is not received within a prespeci?ed number of token rounds,the retransmission layer skips the missing message(s),and resumes forwarding the available ones up to (which then detects a receive omission and reacts accordingly as described in Section5).

5.Admission Control

In this section we discuss the admission control and schedu-lability analysis of real-time messages in the context of the multicast algorithm presented in the preceding section.This module implements a protocol layer above the RTCast layer to regulate traf?c?ow,although an application may choose to send messages directly to RTCast if hard real-time guar-antees are not required.

Real-time messages may be either periodic or aperiodic.

A periodic real-time message is described by its maxi-mum transmission time,period and deadline,where we assume that.An aperiodic message may be viewed as a periodic one whose period tends to in?nity.Be-fore a real-time message is considered for transmission its deadline must be guaranteed.Guaranteeing the deadline of a periodic message means ensuring that the deadline of each of its instances will be met,provided the sender and re-ceiver(s)do not fail,and the network is not partitioned.The same applies to guaranteeing the deadline of an aperiodic message except that,by de?nition,the message has only one instance.Each message instance has an arrival time,which is the time at which the message is presented by the appli-cation.When an application needs to send a real-time mes-sage it presents the message to the admission control layer for schedulability analysis and deadline guarantee evalua-tion.The layer checks whether or not the message can be scheduled alongside the currently guaranteed messages,de-noted by the set,without causing itself or another mes-sage to miss its deadline.If so,the message is accepted for transmission and its deadline is guaranteed.Otherwise the

message is rejected.Bandwidth is reserved for a guaranteed

periodic message by adding it to set,thereby affecting fu-

ture guarantee decisions.The message is not removed from until so instructed by the application.A guaranteed ape-riodic message remains in set only until it is sent.Non

real-time messages are sent only after real-time messages,

if time permits.

In order to perform schedulability analysis,and in view

of the algorithm presented in the previous section,we can make the following assumptions:

Assumption1:Each sender node has a bounded token

hold time,and a bounded token interarrival time

.

Assumption2:The interval elapsed between the time a message has been transmitted by the sender and the time it has been delivered at the destination(s)is bounded by a known constant.(Note that

,where is the maximum number of al-lowable retransmissions.)

Under the above assumptions we have a suf?cient schedula-

bility condition,given by the following theorem.The proof

of the theorem is detailed[1].

Theorem1A set of messages presented by node is

schedulable if

7It is true however,that a collision may occur if two joining processes at-tempt to use the join slot simultaneously.For the sake of building a working prototype on the available hardware we presently circumvent this problem by preventing simultaneous joins

Process group RT-Mach 3.0 x-Kernel 3.2

Figure6.The protol testbed

of retransmissions,,as described in Section4.6.These are accounted for as described in Section5.In the present im-plementation,retransmissions are not supported.Each ma-chine on the private LAN,runs the CMU Real-Time Mach 3.0operating system.All machines are members of a single logical ring.Figure6illustrates the testbed.

6.1.Protocol stack layers

We implement the communication service as a protocol de-veloped with x-Kernel3.2protocol implementation environ-ment.The protocol stack is shown in Figure7.Each box represents a separate protocol layer.The primary advantage of using x-Kernel is the ability to easily recon?gure the pro-tocol stack according to application needs by adding or re-moving corresponding protocols.

The maximum functionality is attained by con?guring the protocol stack as shown in Figure7(a).The ACSA layer performs admission control and schedulability analy-sis(as described in Section5)to guarantee hard real-time deadlines of dynamically arriving messages and periodic connection requests.The RTCast layer implements the mul-ticast and membership service as described in Section4. The Retransmission layer is responsible for handling re-transmissions as described in Section4.6.ClockSync imple-ments a clock synchronization service.In our present sys-tem,uses the probabilistic clock synchroniza-tion algorithm developed by Cristian[9].It uses the under-ACSA

RTCast

Retransmission ClockSync x-kernel transport layer RTCast

x-kernel transport layer

Application Level

Minimal Configuration.

(b)

Full Configuration

(a)

Figure7.The x-kernel protocol stack lying unreliable messaging service provided in the x-Kernel environment.

In soft real-time systems,non real-time systems,or systems where hard real-time communication has been prescheduled and guaranteed a priori,we may wish to omit the ACSA layer,in which case the application interfaces di-rectly to RTCast.The RTCast layer provides a subset of ACSA s API including message send and receive calls, but does not compute deadline guarantees.

If the underlying network is suf?ciently reliable,we may choose to disallow message retransmissions deeming mes-sage omission very unlikely.This will enable supporting tighter deadlines,since we need not account for retransmis-sions when computing worst case deadline guarantees.This can be done by removing the Retransmission layer from the protocol stack8.

Finally,note that ClockSync is needed only to implement assumptions P2and P3(Section3).In the special case of a broadcast LAN,network hardware satis?es these assump-tions obviating the need for ClockSync.

Thus,the minimal con?guration of the protocol stack consists of the RTCast layer alone,as shown in Fig-ure7(b).This con?guration,when used on a broadcast LAN,supports bounded message transport delays,provides atomic ordered multicast,and implements a group mem-bership service that guarantees atomic ordered membership changes,and agreement on group membership view.

6.2.RTCast message types

As mentioned in Section1,RTCast is the essential layer of our group communication service.It is implemented by the two event handlers,message reception handler and token handler.

Figure8shows the different types of messages,and their formats,as well as the header format.Only the atomic or-dered message types and the heartbeat/token type are illus-trated.Atomic ordered types refer to messages guaranteed to be multicast atomically and in total order.When imple-menting the protocol we found it useful to support unreli-able messages too,whose atomicity and order need not be guaranteed.These messages simply do not have sequence numbers.Thus,their omission is undetectable,and their or-der is not speci?ed.For example,they are useful to imple-ment voting.A given sender suggests a“proposition”,then waits to receive“votes”from other group members before deciding whether or not some change should be(atomically) enacted.An instance of voting in our algorithm is to decide on a new member join when the current token rotation time needs to be increased.

Figure8.Message types

6.3Protocol testing

Preliminary testing was performed to verify experimentally the behavior of the implemented protocol layers.The RT-Cast layer was tested?rst to verify its support for system consistency,then the ACSA layer was added,and the system was tested for deadline guarantees.

The RTCast protocol was tested employing the x-Kernel trace library to log the occurrence of certain major events at run-time.Major events include:sending and receiving of messages and heartbeats,token receipt(or timeout),“rota-tion”of current sender,detection of receive omissions and processor crashes,membership changes resulting from pro-cessor crashes,joins and leaves,and processor state transi-tions(between the running,crashed and joining states).

The system was run with event logging on the current testbed.Logs were then veri?ed for conformity to intended semantics.Processor crash and receive omission failures where instrumented by introducing a uniformly distributed random variable for each type of instrumented failure.The current value of each variable was used to determine if the corresponding failure should be introduced next.These val-ues were computed periodically.The probability of each failure was controlled by specifying the subrange of the cor-responding random variable for which the failure is intro-duced.Crash failures were introduced by letting the failed processor go to the crashed state,from which it later recov-ers into the joining state to rejoin the group.Receive omis-sion failures were introduced simply by dropping the next incoming message.Logs were then manually checked for order and atomicity of multicasts and membership changes, as well as agreement on membership view.In a subse-quent set of experiments,the instrumented failures them-selves were logged too,and logs were checked for correct failure detection as well.

To test the real-time behavior of the system,the protocol stack was con?gured with both ACSA and RTCast(with in-strumented failures)present.Trace statements where used in the ACSA layer to record message arrival times and dead-lines.The RTCast was used to log the receipt time of each message.It was veri?ed that all messages guaran-teed by ACSA made it to all destinations by their respec-tive deadlines,unless the destination crashed.The mes-sages themselves,in all experiments,were generated syn-thetically.More details regarding performance evaluation are reported in[1].

7.Conclusions

In this paper we presented RTCast,a new multicast and membership protocol to support fault-tolerant real-time applications.Our approach follows the process group paradigm in which a group of cooperating processes per-form application tasks.We combine the?exibility of an event-triggered approach with bounded message transport and immediate message delivery upon receipt,without sac-ri?cing order,atomicity,and agreement.In addition,RT-Cast supports on-line admission and schedulability anal-ysis of periodic and dynamically arriving aperiodic mes-sages.Finally,our implementation separates support for group management and fault-tolerant multicast from that of system timeliness by dividing functionality into two distinct layers,RTCast and ACSA respectively.The design is such that RTCast may be used alone if support for hard real-time guarantees is not required.

As discussed in Section1,RTCast represents part of a larger middleware service architecture providing group communication support for embedded real-time applica-tions.As such,our current implementation realizes a sub-set of the suite of services outlined in Figure1.We intend to improve the current preliminary implementation and con-tinue toward the goal of developing a composable toolkit for provision of group communication support.Further ar-eas of research on RTCast in particular include additional experiments to better characterize the performance and fail-ure detection capability of the algorithm,investigation into techniques to exploit broadcast networks such as FDDI by ?ne-tuning the algorithms,and an extension of the protocol to support multiple process groups running on overlapping processors.

Acknowledgment

The authors wish to thank Jia-Jang Liou for his assistance in implementing the membership and clock synchronization services.

References

[1]T.Abdelzaher,A.Shaikh,F.Jahanian,and K.Shin.Rtcast:

Lightweight multicast for real-time process groups.Tech-nical report,Dept.of Elec.Engineering and Comp.Science, University of Michigan,January1996.

[2]Y.Amir,D.Dolev,S.Kramer,and D.Malki.Membership

algorithms for multicast communication groups.In Proc.6th International Workshop on Distributed Algorithms,number 647in Lecture Notes in Computer Science,pages292–312, Haifa,Israel,November1992.

[3]Y.Amir,D.Dolev,S.Kramer,and D.Malki.Transis:A com-

munication sub-system for high availability.Technical Re-port TR CS91-13,Dept.of Computer Science,Hebrew Uni-versity,April1992.

[4]Y.Amir,L.Moser,P.Melliar-Smith,D.Agarwal,and P.Cia-

rfella.The Totem single-ring ordering and membership pro-tocol.ACM Transactions on Computer Systems,13(4):311–342,November1995.

[5]K.Birman,A.Schiper,and P.Stephenson.Lightweight

causal and atomic group multicast.ACM Transactions on Computer Systems,9(3):272–314,August1991.

[6]K.P.Birman.The process group approach to reliable

distributed https://www.doczj.com/doc/d314947333.html,munications of the ACM, 36(12):37–53,December1993.

[7]J.-M.Chang and N.Maxemchuk.Reliable broadcast pro-

tocols.ACM Transactions on Computer Systems,2(3):251–273,August1984.

[8] B.Chen,S.Kamat,and W.Zhao.Fault-tolerant real-time

communication in fddi-based networks.In Proc.16th IEEE Real-Time Systems Symposium,pages141–150,Pisa,Italy, December1995.

[9] F.Cristian.Probabilistic clock synchronization.Distributed

Computing,3:146–158,1989.

[10] F.Cristian.Reaching agreement on processor-group mem-

bership in synchronous distributed systems.Distributed Computing,4:175–187,1991.

[11] F.Cristian,B.Dancy,and J.Dehn.Fault-tolerance in the ad-

vanced automation system.In Proc.of Fault-Tolerant Com-puting Symposium,pages6–17,June1990.

[12] F.Jahanian,S.Fakhouri,and R.Rajkumar.Processor group

membership protocols:Speci?cation,design,and imple-mentation.In Proc.12th Symposium on Reliable Distributed Systems,pages2–11,1993.

[13]H.Kopetz and G.Gr¨u nsteidl.TTP–a protocol for fault-

tolerant real-time systems.IEEE Computer,27(1):14–23, January1994.

[14]https://www.doczj.com/doc/d314947333.html,mport.Time,clocks,and the ordering of events in a

distributed https://www.doczj.com/doc/d314947333.html,municationsof the ACM,21(7):558–565,July1978.

[15]S.Mishra,L.Peterson,and R.Schlichting.Consul:A com-

munication substrate for fault-tolerant distributed programs.

Distributed Systems Engineering Journal,1(2):87–103,De-cember1993.

[16]R.Rajkumar,M.Gagliardi,and L.Sha.The real-time

publisher/subscriberinter-process communication model for distributed real-time systems:Design and implementation.

In Proc.Real Time Technologyand Applications Symposium, pages66–75,Chicago,IL,May1995.[17] A.M.Ricciardi and K.P.Birman.Process membership in

asynchronous environments.Technical Report TR93-1328, Dept.of Computer Science,Cornell University,February 1993.

[18]L.Rodrigues,P.Ver′issimo,and J.Ru?no.A low-level

processor group membership protocol for LANs.In Proc.

Int.Conf.on Distributed Computer Systems,pages541–550, 1993.

[19]R.van Renesse,T.Hickey,and K.Birman.Design and per-

formance of Horus:A lightweight group communications system.Technical Report TR94-1442,Dept.of Computer Science,Cornell University,August1994.

初中英语介词用法总结

初中英语介词用法总结 介词(preposition):也叫前置词。在英语里,它的搭配能力最强。但不能单独做句子成分需要和名词或代词(或相当于名词的其他词类、短语及从句)构成介词短语,才能在句中充当成分。 介词是一种虚词,不能独立充当句子成分,需与动词、形容词和名词搭配,才能在句子中充当成分。介词是用于名词或代词之前,表示词与词之间关系的词类,介词常与动词、形容词和名词搭配表示不同意义。介词短语中介词后接名词、代词或可以替代名词的词(如:动名词v-ing).介词后的代词永远为宾格形式。介词的种类: (1)简单介词:about, across, after, against, among, around, at, before, behind, below, beside, but, by, down, during, for, from, in, of, on, over, near, round, since, to, under, up, with等等。 (2)合成介词:inside, into, outside, throughout, upon, without, within (3)短语介词:according to, along with, apart from, because of, in front of, in spite of, instead of, owing to, up to, with reguard to (4)分词介词:considering, reguarding, including, concerning 介词短语:构成 介词+名词We go to school from Monday to Saturday. 介词+代词Could you look for it instead of me? 介词+动名词He insisted on staying home. 介词+连接代/副词I was thinking of how we could get there. 介词+不定式/从句He gives us some advice on how to finish it. 介词的用法: 一、介词to的常见用法 1.动词+to a)动词+ to adjust to适应, attend to处理;照料, agree to赞同,

超全的英语介词用法归纳总结

超全的英语介词用法归纳总结常用介词基本用法辨析 表示方位的介词:in, to, on 1. in 表示在某地范围之内。 Shanghai is/lies in the east of China. 上海在中国的东部。 2. to 表示在某地范围之外。 Japan is/lies to the east of China. 日本位于中国的东面。 3. on 表示与某地相邻或接壤。 Mongolia is/lies on the north of China. 蒙古国位于中国北边。 表示计量的介词:at, for, by 1. at 表示“以……速度”“以……价格”。 It flies at about 900 kilometers an hour. 它以每小时900公里的速度飞行。 I sold my car at a high price. 我以高价出售了我的汽车。 2. for 表示“用……交换,以……为代价”。 He sold his car for 500 dollars. 他以五百元把车卖了。 注意:at表示单价(price) ,for表示总钱数。

3. by 表示“以……计”,后跟度量单位。 They paid him by the month. 他们按月给他计酬。 Here eggs are sold by weight. 在这里鸡蛋是按重量卖的。 表示材料的介词:of, from, in 1. of 成品仍可看出原料。 This box is made of paper. 这个盒子是纸做的。 2. from 成品已看不出原料。 Wine is made from grapes. 葡萄酒是葡萄酿成的。 3. in 表示用某种材料或语言。 Please fill in the form in pencil first. 请先用铅笔填写这个表格。They talk in English. 他们用英语交谈。 表示工具或手段的介词:by, with, on 1. by 用某种方式,多用于交通。 I went there by bus. 我坐公共汽车去那儿。 2. with表示“用某种工具”。 He broke the window with a stone. 他用石头把玻璃砸坏了。注意:with表示用某种工具时,必须用冠词或物主代词。

批处理命令行for语句

for语句可以在命令行提示符中使用,也可以在批处理文件中使用。这两种情况下唯一的区别是%和%%,参加下文说明。 一、for语句的格式: for [参数] 变量in (集合) do 命令[命令的参数] 二、for语句的作用:对集合内的元素逐一执行后面的命令。 1、如:for %%i in (你好) do echo %%i 将在屏幕上显示“你好”2个字。这里集合是“你好”,执行的命令是“echo”。由于集合中只有1个元素,因此循环只运行一次。 如果改成for %%i in (你好朋友) do echo %%i 将会显示2行文字,第一行为“你好”,第二行为“朋友”。因为2个词之间有空格,因此集合中就有了2个元素,循环将运行2次。 2、注意:以上for语句的运行方式是新建一个批处理文件,即扩展名为“.bat”的文件,内容为上面的命令,然后运行。为了批处理执行完不退出,可在最后加上一条pause>null命令,这样能看到执行的结果。要想通过cmd命令行执行的话,必须将%%换成%,即去掉一个%,如下: for %i in (你好) do echo %i 3、以下所有例子都是这样,若要在命令行提示符下执行,请将所有的%%改成一个%。 三、for语句详细说明: 上面语句格式中有的加了中括号[],表示这个语句元素不是必须的,只在需要时使用。像刚才显示“你好”的命令中就没有使用[参数]这

个语句元素。所有语句元素间用空格隔开。 各语句元素的写法:for、in、do这3个符号是固定不变的 1、[参数]的种类:只有4种,分别是/d、/r、/l、/f(即目录Directory、递归recursion、序列list、文件file),他们用于对后面的集合的含义做出解释,请与下面的集合解释结合来看。这4个参数不区分大小写,可以联合使用,即一条for语句可以出现多个参数。 2、变量:除10个数字外(0-9)的所有符号(因为0-9往往作为形参使用,为了与此区别),变量名一般用单个字母表示即可,而且变量名区分大小写,即A和a是两个不同的变量。变量名前面必须是%,当在命令提示符下执行时,只用一个%;而在批处理程序中,必须用%%。 一行语句中,一般只需定义一个变量。使用/f参数中的tokens 选项可以将集合中的元素分解成多个值,并自动定义新的变量对应这些值。这时语句中可以使用多个变量,通常按字母顺序命名,即第一个是%%a,那么后一个就用%%b。如果第一个是%%i,后一个就用%%j。依此类推。具体看后面的相关内容。 变量可以直接在do后面的命令中使用。每次使用的变量总数不超过52个。 3、集合:集合必须放在括号里。集合是一行文本,这行文本可能有几种类型,如“你好”只是一串字符;“c:\boot.ini”是一个文件;“dir /b”是一个命令。 (1)如果for语句中没有使用任何参数,对待集合文本的处理方式是:

(完整版)介词for用法归纳

介词for用法归纳 用法1:(表目的)为了。如: They went out for a walk. 他们出去散步了。 What did you do that for? 你干吗这样做? That’s what we’re here for. 这正是我们来的目的。 What’s she gone for this time? 她这次去干什么去了? He was waiting for the bus. 他在等公共汽车。 【用法说明】在通常情况下,英语不用for doing sth 来表示目的。如: 他去那儿看他叔叔。 误:He went there for seeing his uncle. 正:He went there to see his uncle. 但是,若一个动名词已名词化,则可与for 连用表目的。如: He went there for swimming. 他去那儿游泳。(swimming 已名词化) 注意:若不是表目的,而是表原因、用途等,则其后可接动名词。(见下面的有关用法) 用法2:(表利益)为,为了。如: What can I do for you? 你想要我什么? We study hard for our motherland. 我们为祖国努力学习。 Would you please carry this for me? 请你替我提这个东西好吗? Do more exercise for the good of your health. 为了健康你要多运动。 【用法说明】(1) 有些后接双宾语的动词(如buy, choose, cook, fetch, find, get, order, prepare, sing, spare 等),当双宾语易位时,通常用for 来引出间接宾语,表示间接宾语为受益者。如: She made her daughter a dress. / She made a dress for her daughter. 她为她女儿做了件连衣裙。 He cooked us some potatoes. / He cooked some potatoes for us. 他为我们煮了些土豆。 注意,类似下面这样的句子必须用for: He bought a new chair for the office. 他为办公室买了张新办公椅。 (2) 注意不要按汉语字面意思,在一些及物动词后误加介词for: 他们决定在电视上为他们的新产品打广告。 误:They decided to advertise for their new product on TV. 正:They decided to advertise their new product on TV. 注:advertise 可用作及物或不及物动词,但含义不同:advertise sth=为卖出某物而打广告;advertise for sth=为寻找某物而打广告。如:advertise for a job=登广告求职。由于受汉语“为”的影响,而此处误加了介词for。类似地,汉语中的“为人民服务”,说成英语是serve the people,而不是serve for the people,“为某人的死报仇”,说成英语是avenge sb’s death,而不是avenge for sb’s death,等等。用法3:(表用途)用于,用来。如: Knives are used for cutting things. 小刀是用来切东西的。 This knife is for cutting bread. 这把小刀是用于切面包的。 It’s a machine for slicing bread. 这是切面包的机器。 The doctor gave her some medicine for her cold. 医生给了她一些感冒药。 用法4:为得到,为拿到,为取得。如: He went home for his book. 他回家拿书。 He went to his friend for advice. 他去向朋友请教。 She often asked her parents for money. 她经常向父母要钱。

【备战高考】英语介词用法总结(完整)

【备战高考】英语介词用法总结(完整) 一、单项选择介词 1. passion, people won't have the motivation or the joy necessary for creative thinking. A.For . B.Without C.Beneath D.By 【答案】B 【解析】 【详解】 考查介词辨析。句意:没有激情,人们就不会有创新思维所必须的动机和快乐。A. For 对于;B. Without没有; C. Beneath在……下面 ; D. By通过。没有激情,人们就不会有创新思维所必须的动机和快乐。所以空处填介词without。故填without。 2.Modern zoos should shoulder more social responsibility _______ social progress and awareness of the public. A.in light of B.in favor of C.in honor of D.in praise of 【答案】A 【解析】 【分析】 【详解】 考查介词短语。句意:现代的动物园应该根据社会的进步和公众的意识来承担更多的社会责任。A. in light of根据,鉴于;B. in favor of有利于,支持;C. in honor of 为了纪念;D. in praise of歌颂,为赞扬。此处表示根据,故选A。 3.If we surround ourselves with people _____our major purpose, we can get their support and encouragement. A.in sympathy with B.in terms of C.in honour of D.in contrast with 【答案】A 【解析】 【详解】 考查介词短语辨析。句意:如果我们周围都是认同我们主要前进目标的人,我们就能得到他们的支持和鼓励。A. in sympathy with赞成;B. in terms of 依据;C. in honour of为纪念; D. in contrast with与…形成对比。由“we can get their support and encouragement”可知,in sym pathy with“赞成”符合句意。故选A项。 4.Elizabeth has already achieved success_____her wildest dreams. A.at B.beyond C.within D.upon

英语介词for的用法归纳总结.doc

英语介词for的用法归纳总结用法1:(介词for表目的)为了 They went out for a walk. 他们出去散步了。 What did you do that for? 你干吗这样做? That s what we re here for. 这正是我们来的目的。 What s she gone for this time? 她这次去干什么去了? He was waiting for the bus. 他在等公共汽车。 【用法说明】在通常情况下,英语不用for doing sth 来表示目的 他去那儿看他叔叔。 误:He went there for seeing his uncle. 正:He went there to see his uncle. 但是,若一个动名词已名词化,则可与for 连用表目的 He went there for swimming. 他去那儿游泳。(swimming 已名词化) 注意:若不是表目的,而是表原因、用途等,则其后可接动名词。(见下面的有关用法) 用法2:(介词for表利益)为,为了 What can I do for you? 你想要我什么? We study hard for our motherland. 我们为祖国努力学习。 Would you please carry this for me? 请你替我提这个东西好吗?

Do more exercise for the good of your health. 为了健康你要多运动。 【用法说明】(1) 有些后接双宾语的动词(如buy, choose, cook, fetch, find, get, order, prepare, sing, spare 等),当双宾语易位时,通常用for 来引出间接宾语,表示间接宾语为受益者 She made her daughter a dress. / She made a dress for her daughter. 她为她女儿做了件连衣裙。 He cooked us some potatoes. / He cooked some potatoes for us. 他为我们煮了些土豆。 注意,类似下面这样的句子必须用for: He bought a new chair for the office. 他为办公室买了张新办公椅。 (2) 注意不要按汉语字面意思,在一些及物动词后误加介词for: 他们决定在电视上为他们的新产品打广告。 误:They decided to advertise for their new product on TV. 正:They decided to advertise their new product on TV. 注:advertise 可用作及物或不及物动词,但含义不同:advertise sth=为卖出某物而打广告;advertise for sth=为寻找某物而打广告advertise for a job=登广告求职。由于受汉语为的影响,而此处误加了介词for。类似地,汉语中的为人民服务,说成英语是serve the people,而不是serve for the people,为某人的死报仇,说成英语是avenge sb s death,而不是avenge for sb s death,等等。 用法3:(介词for表用途)用于,用来 Knives are used for cutting things. 小刀是用来切东西的。

介词for用法完全归纳

用法1:(表目的)为了。如: They went out for a walk. 他们出去散步了。 What did you do that for? 你干吗这样做? That’s what we’re here for. 这正是我们来的目的。 What’s she gone for this time? 她这次去干什么去了? He was waiting for the bus. 他在等公共汽车。 【用法说明】在通常情况下,英语不用for doing sth 来表示目的。如:他去那儿看他叔叔。 误:He went there for seeing his uncle. 正:He went there to see his uncle. 但是,若一个动名词已名词化,则可与for 连用表目的。如: He went there for swimming. 他去那儿游泳。(swimming 已名词化) 注意:若不是表目的,而是表原因、用途等,则其后可接动名词。(见下面的有关用法) 用法2:(表利益)为,为了。如: What can I do for you? 你想要我什么? We study hard for our motherland. 我们为祖国努力学习。 Would you please carry this for me? 请你替我提这个东西好吗? Do more exercise for the good of your health. 为了健康你要多运动。 【用法说明】(1) 有些后接双宾语的动词(如buy, choose, cook, fetch, find, get, order, prepare, sing, spare 等),当双宾语易位时,通常用for 来引出间接宾语,表示间接宾语为受益者。如:

批处理命令for语句基本用法

批处理命令for语句的基本用法 [系列教程]批处理for语句从入门到精通[20101225更新] ____________________________版主提醒 ____________________________ 文档来自于网络搜索 为了避免影响技术讨论、提高看帖的舒适性,请大家不要在此帖下跟 无实质内容的口水帖,特别是纯顶、纯支持、纯感谢、路过之类的帖子, 管理人员将不定期清理此类回帖,请大家多参与讨论少灌水,与人方便, 终将给自己带来方便,谢谢合作。 ________________________________________________________________ 文档来自于网络搜索 批处理是一门简单的脚本语言,虽然不能独当一面,但是,若作为工作中的辅助工具,绝对会让大家有随用随写、称心如意的畅快感。 文档来自于网络搜索 和其他语言相比,批处理语言有其先天性的优势: 1、系统自带,无需另行安装; 2、命令少,语句简洁,上手非常快; 3、编写出来的脚本小巧玲珑,随写随用; 但是,因为它以命令行方式工作,操作多有不便,在图形界面大行其道的windows世界里,多多少少会让大众望而却步;就算是对命令行有好感的新手,面对微软有如天书的帮助文件,很多人也会败下阵来,因此,论坛里很多会员也发出了编写系统的批处理教程的呼声。

文档来自于网络搜索 编写系统的批处理新手教程,一直是论坛管理层讨论的热点问题,但是,各位管理人员大多都有工作在身,而系统的教程涉及的面是如此之广,面对如此浩大的工程,仅凭一两个人的力量,是难以做好的,因此,本人退而求其次,此次发布的教程,以专题的形式编写,日后人手渐多之后,再考虑组织人力编写全面的教程。 文档来自于网络搜索之所以选择最难的for,一是觉得for最为强大,是大多数人最希望掌握的;二是若写其他命令教程,如果没有for的基础,展开来讲解会无从下手;三是for也是批处理中最复杂最难掌握的语句,把它攻克了,批处理的学习将会一片坦途。 文档来自于网络搜索 这次的for语句系列教程,打算按照for语句的5种句式逐一展开,在讲解for/f的时候,会穿插讲解批处理中一个最为关键、也是新手最容易犯错的概念:变量延迟,大纲如下: 文档来自于网络搜索一前言 二for语句的基本用法 三for /f(含变量延迟) 四for /r 五for /d 六for /l 遵照yibantiaokuan的建议,在顶楼放出此教程的txt版本、word版本和pdf版本,以方便那些离线浏览的会员。 文档来自于网络搜索[本帖最后由namejm于2010-12-26 02:36编辑]

for的用法完全归纳

for的用法完全归纳 用法1:(表目的)为了。如: They went out for a walk. 他们出去散步了。 What did you do that for? 你干吗这样做? That’s what we’re here for. 这正是我们来的目的。 What’s she gone for this time? 她这次去干什么去了? He was waiting for the bus. 他在等公共汽车。 在通常情况下,英语不用for doing sth 来表示目的。如:他去那儿看他叔叔。 误:He went there for seeing his uncle.正:He went there to see his uncle. 但是,若一个动名词已名词化,则可与for 连用表目的。如: He went there for swimming. 他去那儿游泳。(swimming 已名词化) 注意:若不是表目的,而是表原因、用途等,则其后可接动名词。 用法2:(表利益)为,为了。如: What can I do for you? 你想要我什么? We study hard for our motherland. 我们为祖国努力学习。 Would you please carry this for me? 请你替我提这个东西好吗? Do more exercise for the good of your health. 为了健康你要多运动。 (1)有些后接双宾语的动词(如buy, choose, cook, fetch, find, get, order, prepare, sing, spare 等),当双宾语易位时,通 常用for 来引出间接宾语,表示间接宾语为受益者。如: She made her daughter a dress. / She made a dress for her daughter. 她为她女儿做了件连衣裙。 He cooked us some potatoes. / He cooked some potatoes for us. 他为我们煮了些土豆。 注意,类似下面这样的句子必须用for: He bought a new chair for the office. 他为办公室买了张新办公椅。 (2) 注意不要按汉语字面意思,在一些及物动词后误加介词for: 他们决定在电视上为他们的新产品打广告。 误:They decided to advertise for their new product on TV. 正:They decided to advertise their new product on TV. 注:advertise 可用作及物或不及物动词,但含义不同:advertise sth=为卖出某物而打广告;advertise for sth=为寻找某物而打广告。如:advertise for a job=登广告求职。由于受汉语“为”的影响,而此处误加了介词for。类似地,汉语中的“为人民服务”,说成英语是serve the people,而不是serve for the people,“为某人的死报仇”,说成英语是avenge sb’s death,而不是avenge for sb’s death,等等。 用法3:(表用途)用于,用来。如: Knives are used for cutting things. 小刀是用来切东西的。 This knife is for cutting bread. 这把小刀是用于切面包的。 It’s a machine for slicing bread. 这是切面包的机器。 The doctor gave her some medicine for her cold. 医生给了她一些感冒药。 用法4:为得到,为拿到,为取得。如: He went home for his book. 他回家拿书。 He went to his friend for advice. 他去向朋友请教。 She often asked her parents for money. 她经常向父母要钱。 We all hope for success. 我们都盼望成功。 Are you coming in for some tea? 你要不要进来喝点茶? 用法5:给(某人),供(某人)用。如: That’s for you. 这是给你的。 Here is a letter for you. 这是你的信。 Have you room for me there? 你那边能给我腾出点地方吗? 用法6:(表原因、理由)因为,由于。如:

批处理命令格式

批处理命令格式.txt人永远不知道谁哪次不经意的跟你说了再见之后就真的再也不见了。一分钟有多长?这要看你是蹲在厕所里面,还是等在厕所外面……echo 表示显示此命令后的字符 echo off 表示在此语句后所有运行的命令都不显示命令行本身 @与echo off相象,但它是加在每个命令行的最前面,表示运行时不显示这一行的命令行(只能影响当前行)。 call 调用另一个批处理文件(如果不用call而直接调用别的批处理文件,那么执行完那个批处理文件后将无法返回当前文件并执行当前文件的后续命令)。 pause 运行此句会暂停批处理的执行并在屏幕上显示Press any key to continue...的提示,等待用户按任意键后继续 rem 表示此命令后的字符为解释行(注释),不执行,只是给自己今后参考用的(相当于程序中的注释)。 例1:用edit编辑a.bat文件,输入下列内容后存盘为c: a.bat,执行该批处理文件后可实现:将根目录中所有文件写入 a.txt中,启动UCDOS,进入WPS等功能。 批处理文件的内容为: 命令注释: @echo off 不显示后续命令行及当前命令行 dir c: *.* >a.txt 将c盘文件列表写入a.txt call c: ucdos ucdos.bat 调用ucdos echo 你好显示"你好" pause 暂停,等待按键继续 rem 准备运行wps 注释:准备运行wps cd ucdos 进入ucdos目录 wps 运行wps 批处理文件的参数 批处理文件还可以像C语言的函数一样使用参数(相当于DOS命令的命令行参数),这需要用到一个参数表示符“%”。 %[1-9]表示参数,参数是指在运行批处理文件时在文件名后加的以空格(或者Tab)分隔的字符串。变量可以从%0到%9,%0表示批处理命令本身,其它参数字符串用%1到%9顺序表示。例2:C:根目录下有一批处理文件名为f.bat,内容为: @echo off format %1 如果执行C: >f a: 那么在执行f.bat时,%1就表示a:,这样format %1就相当于format a:,于是上面的命令运行时实际执行的是format a: 例3:C:根目录下一批处理文件名为t.bat,内容为: @echo off type %1 type %2 那么运行C: >t a.txt b.txt %1 : 表示a.txt %2 : 表示b.txt 于是上面的命令将顺序地显示a.txt和b.txt文件的内容。 特殊命令 if goto choice for是批处理文件中比较高级的命令,如果这几个你用得很熟练,你就是批

介词for 的常见用法归纳

介词for 的常见用法归纳 贵州省黔东南州黎平县黎平一中英语组廖钟雁介词for 用法灵活并且搭配能力很强,是一个使用频率非常高的词,也是 高考必考的重要词汇,现将其常见用法归纳如下,供参考。 1.表时间、距离或数量等。 ①意为“在特定时间,定于,安排在约定时间”。如: The meeting is arranged for 9 o’clock. 会议安排在九点进行。 ②意为“持续达”,常于last、stay 、wait等持续性动词连用,表动作持续的时间,有时可以省略。如: He stayed for a long time. 他逗留了很久。 The meeting lasted (for)three hours. 会议持续了三小时。 ③意为“(距离或数量)计、达”。例如: He walked for two miles. 他走了两英里。 The shop sent me a bill for $100.商店给我送来了100美元的账单。 2. 表方向。意为“向、朝、开往、前往”。常与head、leave 、set off、start 等动词连用。如: Tomorrow Tom will leave for Beijing. 明天汤姆要去北京。 He put on his coat and headed for the door他穿上大衣向门口走去。 介词to也可表示方向,但往往与come、drive 、fly、get、go、lead、march、move、return、ride、travel、walk等动词连用。 3.表示理由或原因,意为“因为、由于”。常与thank、famous、reason 、sake 等词连用。如: Thank you for helping me with my English. 谢谢你帮我学习英语。 For several reasons, I’d rather not meet him. 由于种种原因,我宁可不见他。 The West Lake is famous for its beautiful scenery.西湖因美景而闻名。 4.表示目的,意为“为了、取、买”等。如: Let’s go for a walk. 我们出去散步吧。 I came here for my schoolbag.我来这儿取书包。 He plays the piano for pleasure. 他弹钢琴是为了消遣。 There is no need for anyone to know. 没必要让任何人知道。 5.表示动作的对象或接受者,意为“给、为、对于”。如: Let me pick it up for you. 让我为你捡起来。 Watching TV too much is bad for your health. 看电视太多有害于你的健康。 Here is a letter for you. 这儿有你的一封信。

英语介词的用法总结

介词的用法 1.表示地点位置的介词 1)at ,in, on, to,for at (1)表示在小地方; (2)表示“在……附近,旁边” in (1)表示在大地方; (2)表示“在…范围之内”。 on 表示毗邻,接壤,“在……上面”。 to 表示在……范围外,不强调是否接壤;或“到……” 2)above, over, on 在……上 above 指在……上方,不强调是否垂直,与below相对; over指垂直的上方,与under相对,但over与物体有一定的空间,不直接接触。 on表示某物体上面并与之接触。 The bird is flying above my head. There is a bridge over the river. He put his watch on the desk. 3)below, under 在……下面 under表示在…正下方 below表示在……下,不一定在正下方 There is a cat under the table. Please write your name below the line. 4)in front [frant]of, in the front of在……前面 in front of…意思是“在……前面”,指甲物在乙物之前,两者互不包括;其反义词是behind(在……的后面)。There are some flowers in front of the house.(房子前面有些花卉。) in the front of 意思是“在…..的前部”,即甲物在乙物的内部.反义词是at the back of…(在……范围内的后部)。 There is a blackboard in the front of our classroom. 我们的教室前边有一块黑板。 Our teacher stands in the front of the classroom. 我们的老师站在教室前.(老师在教室里) 5)beside,behind beside 表示在……旁边 behind 表示在……后面 2.表示时间的介词 1)in , on,at 在……时 in表示较长时间,如世纪、朝代、时代、年、季节、月及一般(非特指)的早、中、晚等。 如in the 20th century, in the 1950s, in 1989, in summer, in January, in the morning, in one’s life , in one’s thirties等。 on表示具体某一天及其早、中、晚。 如on May 1st, on Monday, on New Year’s Day, on a cold night in January, on a fine morning, on Sunday afternoon等。 at表示某一时刻或较短暂的时间,或泛指圣诞节,复活节等。 如at 3:20, at this time of year, at the beginning of, at the end of …, at the age of …, at Christmas,at night, at noon, at this moment等。 注意:在last, next, this, that, some, every 等词之前一律不用介词。如:We meet every day. 2)in, after 在……之后 “in +段时间”表示将来的一段时间以后; “after+段时间”表示过去的一段时间以后; “after+将来的时间点”表示将来的某一时刻以后。 3)from, since 自从…… from仅说明什么时候开始,不说明某动作或情况持续多久;

批处理基础知识

批处理文件基础知识 一、单符号message指定让MS-DOS在屏幕上显示的正文 ~ ①在for中表示使用增强的变量扩展。 ②在%var:~n,m%中表示使用扩展环境变量指定位置的字符串。 ③在set/a中表示一元运算符,将操作数按位取反。 ! ①在set /a中一元运算符,表示逻辑非。比如set /a a=!0,这时a就表示逻辑1。 @ ①隐藏命令行本身的回显,常用于批处理中。 % ①在set /a中的二元运算符,表示算术取余。 ②命令行环境下,在for命令in前,后面接一个字符(可以是字母、数字或者一些特定字符),表示指定一个循环或者遍历指标变量。 ③批处理中,后接一个数字表示引用本批处理当前执行时的指定的参数。 ④其它情况下,%将会被脱去(批处理)或保留(命令行) ^ ①取消特定字符的转义作用,比如& | > < ! "等,但不包括%。比如要在屏幕显示一些特殊的字符,比如> >> | ^ &等符号时,就可以在其前面加一个^符号来显示这个^后面的字符了,^^就是显示一个^,^|就是显示一个|字符了; ②在set/a中的二元运算符,表示按位异或。 ③在findstr/r的[]中表示不匹配指定的字符集。 & ①命令连接字符。比如我要在一行文本上同时执行两个命令,就可以用&命令连接这两个命令。 ②在set/a中是按位与。 : ①标签定位符,表示其后的字符串为以标签,可以作为goto命令的作用对象。比如在批处理文件里面定义了一个":begin"标签,用"goto begin"命令就可以转到":begin"标签后面来执行批处理命令了。 ②在%var:string1=string2%中分隔变量名和被替换字串关系。 | ①管道符,就是将上一个命令的输出,作为下一个命令的输入."dir /a/b |more"就可以逐屏的显示dir命令所输出的信息。 ②在set/a中的二元运算符,表示按位或。 ③在帮助文档中表示其前后两个开关、选项或参数是二选一的。 / ①表示其后的字符(串)是命令的功能开关(选项)。比如"dir /s/b/a-d"表示"dir"命令指定的不同的参数。 ②在set/a中表示除法。 > ①命令重定向符,将其前面的命令的输出结果重新定向到其后面的设备中去,后面的设备中的内容被覆盖。比如可以用"dir > lxmxn.txt"将"dir"命令的结果输出到"lxmxn.txt"这个文本文件中去。 ②在findstr/r中表示匹配单词的右边界,需要配合转义字符\使用。 < ①将其后面的文件的内容作为其前面命令的输入。 ②在findstr/r中表示匹配单词的左边界,需要配合转义字符\使用。 . ①在路径的\后紧跟或者单独出现时:

介词的归纳

介词的归纳 一、单项选择介词 1.(重庆)Last year was the warmest year on record, with global temperature 0.68 ℃ ________ the average. A.below B.on C.at D.above 【答案】D 【解析】 【详解】 考查介词。句意:去年是有纪录以来最热的一年,全球平均气温上升0.68度。A. below低于;B. on在……之上;C. at在;D. above超过,多于。根据前一句Last year was the warmest year on record推知,温度应该是上升了,故用介词above。 【点睛】 with的复合结构中,复合宾语中第一部分宾语由名词和代词充当,第二部分补足语由形容词,副词,介词短语,动词不定式或分词充当。而本题考查with +名词/代词+介词短语,而介词的使用则根据当时语境的提示来做出相应的变化即句中的the warmest year on record 起重要作用,可知高出平均气温。 2.According to Baidu, the high-quality content of Cloud Music will reach massive users _______ Baidu’s app and video platform. A.in honor of B.in view of C.by virtue of D.by way of 【答案】C 【解析】 【详解】 考查介词短语。句意:根据百度的说法,云音乐的高质量内容将借助于百度应用和视频平台到达广大用户。A. in honor of向……致敬;B. in view of考虑到;C. by virtue of借助于;D. by way of通过。根据句意可知,此处要表达“借助于”。故选C项。 3.We charge parcels ________ weight, rather than individual units. A.in honor of B.in contact with C.in terms of D.in connection with 【答案】C 【解析】 【详解】 考查介词短语。句意:我们根据包裹的重量,而不是包裹的件数收费。A. in honor of为了对……表示敬意;B. in contact with与……有联系,接触;C. in terms of根据,在……方面;D. in connection with与……有关,有联系。表示根据什么计费。故选C。 【点睛】

介词用法归纳

介词(preposition) 又称前置词,是一种虚词。介词不能单独做句子成分。介词后须接宾语,介词与其宾语构成介词短语。 一、介词从其构成来看可以分为: 1、简单介词(Simple prepositions)如:at ,by, for, in, from, since, through等; 2、复合介词(Compound prepositions)如:onto, out of, without, towards等; 3、短语介词(phrasal prepositions)如;because of, instead of, on account of, in spite of, in front of等; 4、二重介词(double prepositions)如:from behind, from under, till after等; 5、分词介词(participial prepositions),又可称动词介词(verbal prepositions)如:during, concerning, excepting, considering, past等。 二、常见介词的基本用法 1、 about 关于 Do you know something about Tom? What about this coat?(……怎么样) 2、 after 在……之后 I’m going to see you after supper. Tom looked after his sick mother yesterday.(照看) 3、 across 横过 Can you swim across the river. 4、 against 反对 Are you for or against me? Nothing could make me turn against my country.(背叛) 5、 along 沿着 We walked along the river bank. 6、 before 在……之前 I hope to get there before seven o’clock. It looks as though it will snow before long.(不久) 7、behind 在……后面 The sun is hidden behind the clouds. 8、by 到……时 We had learned ten English songs by the end of last term. 9、during 在……期间 Where are you going during the holiday. 10、except 除了 Everyone except you answered the question correctly. 11、for 为了 The students are studying hard for the people. 12、from 从 I come from Shanghai. 13、in 在……里 on 在……上面 under在……下面 There are two balls in/on/under the desk. 14、near 在……附近 We live near the park. 15、of ……的 Do you know the name of the winner. 16、over 在……正上方 There is a bridge over the river. Tom goes over his English every day.(复习) 17、round/around 围绕 The students stand around the teacher. 18、to 朝……方向 Can you tell me the way to the cinema. 19、towards朝着 The car is traveling towards Beijing.

相关主题
相关文档 最新文档