concurrency pattern

enzo_

De opdracht is het schrijven van een verslag waarin je een concurrency pattern beschrijft. In het verslag moet aandacht zijn voor de volgende aspecten:

- naam pattern

- welk ontwerp probleem moet dit pattern oplossen?

- hoe wordt dit ontwerp probleem opgelost ?

- noem een aantal veel voorkomende toepassingen van dit pattern

- geef een code voorbeeld van dit pattern, in Java, C# of PHP

- het code voorbeeld mag een bestaand voorbeeld zijn maar je moet het van een zelfgeschreven toelichting voorzien

- het verslag is de Nederlandse taal geschreven

- geen copy & paste van bestaande teksten van internet

Voorbeelden van concurrency patterns zijn:

- Active Object

- Balking pattern

- Double checked locking pattern

- Guarded suspension

- Leaders/followers pattern

- Monitor Object

- Read write lock pattern

- Scheduler pattern

- Thread pool pattern

- Thread-Specific Storage

- Reactor pattern

pleaassee iemand die me kan helpen ???

ik kan haast geen informatie over ze vinden ,....

Brinx

Geduld is een schone zaak. Dit forum is natuurlijk geen 1-uurs-helpservice! Als je een nieuw onderwerp hebt gepost is het gewoon een kwestie van wachten op een antwoord. Je eigen onderwerp 'bumpen' (wat je nu deed) is slechte etiquette.

enzo_

Geduld is een schone zaak. Dit forum is natuurlijk geen 1-uurs-helpservice! Als je een nieuw onderwerp hebt gepost is het gewoon een kwestie van wachten op een antwoord. Je eigen onderwerp 'bumpen' (wat je nu deed) is slechte etiquette.

oke dan wacht ik wel af .... dank je wel

oktagon

probeer eens:

http://europa.eu/index_nl.htm

misschien levert dat wat op!

enzo_

oktagon schreef:probeer eens:

http://europa.eu/index_nl.htm

misschien levert dat wat op!

wat moet ik dan hier zien ?

Brinx

In de links vanaf dit wikipedia artikel worden veel van de concurrency patterns beschreven:

http://en.wikipedia.org/wiki/Concurrency_pattern

Had je daar al gekeken?

enzo_

Brinx schreef:In de links vanaf dit wikipedia artikel worden veel van de concurrency patterns beschreven:

http://en.wikipedia.org/wiki/Concurrency_pattern

Had je daar al gekeken?

ja dat heb ik al gekeken maar ik schiet er niet mee op ...

Brinx

Maar wat mankeert er aan die uitleg? Is het de taal die je problemen bezorgt, of ben je gewoon op zoek naar andere soorten informatie?

enzo_

Maar wat mankeert er aan die uitleg? Is het de taal die je problemen bezorgt, of ben je gewoon op zoek naar andere soorten informatie?

Hoi brinx dat je wel dat je me helpt aller eerst ....

Ik heb meer info gevonden over sheduler pattern op

http://web.cs.wpi.edu/~gpollice/cs509-s04/.../scheduler.html

alleen ik begrijp er eigelijk niks van .........

enzo_

enzo_ schreef:Hoi brinx dat je wel dat je me helpt aller eerst ....

Ik heb meer info gevonden over sheduler pattern op

http://web.cs.wpi.edu/~gpollice/cs509-s04/.../scheduler.html

alleen ik begrijp er eigelijk niks van .........

Ik heb wat informatie gevonden erover

kan iemand me helpen met dit te vertalen want als ik het met een vertaal machine dit vertaal dan snap ik er niks van

The solution is to make a Scheduler object that has a function call that will not return until it is that thread's turn to use the processor.

Afbeelding

FIGURE 2: Classes for the Scheduler Pattern

Here are descriptions of the roles the classes play in the Scheduler pattern:

Request. Classes in this role must implement the interface in the ScheduleOrdering role. Request objects encapsulate a request for a Processor object to do something.

Processor. Instances of classes in this role perform a computation described by a Request object. They may be presented with more than one Request object to process at a time, but they can process only one at a time. A Processor object delegates to a Scheduler object the responsibility for scheduling Request objects for processing, one at a time.

Scheduler. Instances of classes in this role schedule Request objects for processing by a Processor object. To promote reusability, a Scheduler class does not have any knowledge of the Request class that it schedules. Instead, it accesses Request objects through the ScheduleOrdering interface that they im plement.

A class in this role is responsible for deciding when the next request will run. It is not responsible for the order in which the requests will run. It delegates that responsibility to a ScheduleOrdering interface.

ScheduleOrdering. Request objects implement the interface that is in this role. Interfaces in this role serve two purposes:

By referring to a ScheduleOrdering interface, Processor classes avoid a dependency on a Request class.

By calling methods defined by the ScheduleOrdering interface, Scheduler classes are able to delegate the decision about which Request object will be processed next. This increases the reusability of Scheduler classes. The class diagram in Figure 1 indicates one such method, named scheduleBefore.

Afbeelding

FIGURE 2: Interaction between objects.

The interaction between a Processor object and a Scheduler object occurs in two stages, as shown by the collaboration diagram in Figure 2.

The first interaction in Figure 2 is a call to a Processor objects doIt method. The first thing the doIt method does is call the enter method of the Scheduler object associated with the Processor object. If there is no other thread currently executing the rest of the doIt method, then the enter method returns immediately. After the enter method returns, the Scheduler object knows that the resource it manages is busy. While its resource is busy, any calls to the Scheduler objects enter method will not return until the resource is not busy and the Scheduler object decides it is that calls turn to return.

A Scheduler object considers the resource it manages to be busy until the Scheduler objects done method is called. When one thread makes a valid call to a Scheduler objects done method, if any threads are waiting to return from the Scheduler objects enter method, then one of them returns.

If a call to a Scheduler objects enter method must wait before it returns and there are other calls waiting to return from the enter method, then the Scheduler object must decide which call will return next. It decides by consulting the Request objects that were passed into those calls to decide which call will return next. It does this indirectly by calling methods declared for the purpose by the ScheduleOrdering interface and implemented by the Request object.

enzo_

Request. Classes in this role must implement the interface in the ScheduleOrdering role. Request objects encapsulate a request for a Processor object to do something.

vertaling

Request : De Classes moet uitgevoerd worden in de interface ScheduleOrdering. De Request objects verzoek de Processor object voor een actie.

klopt dit ??

Yogy

Ik denk dat je zal moeten zoeken in de richting van databanken:

Met die concurrency bedoelen ze dat er 2 of meer verschillende " Threads " gebruik maken van hetzelfde object.

en dit object eventueel veranderen.

dit wordt meestal opgelost door " locks " op een object te zetten. Als een Thread dan gebruik wilt maken van een object, dan kan hierop een lock gezet worden zodat een andere thread die hiervan gebruik wilt maken, moet wachten totdat het object gereleased ( ge-Unlocked ) is

Ik geloof dat het meest voorkomende pattern phase 2 phase pattern is.

ik hoop dat ik je hier iets of wat mee geholpen heb.

enzo_

Klopt deze zin ' pi.gif ?

Processor. Instances of classes in this role perform a computation described by a Request object. They may be presented with more than one Request object to process at a time, but they can process only one at a time. A Processor object delegates to a Scheduler object the responsibility for scheduling Request objects for processing, one at a time.

Processor: De klassen voert in deze rol een berekening uit die door Request objects word beschreven Ze kunnen meerdere één Request object ontvangen, maar zij kunnen slechts een voor een verwerkt worden. De Processor object vaardig af namens aan de Request objects de verantwoordelijkheid voor de verwerking object Request objects.

Wetenschapsforum

Laatste berichten

Nieuwsberichten

concurrency pattern

Re:

Re:

Re:

Re:

Re:

Re:

Re:

Re:

Re:

Re:

Re:

Re: