Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (601)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Multi-blocking pattern  (Read 3535 times)
0 Members and 1 Guest are viewing this topic.
Offline keldon85

Senior Devvie


Medals: 1



« Posted 2007-08-10 20:43:25 »

As some of you know I'm currently preparing for a set of interviews for a job, and in the process of patching old work for show I came across an idea for a pattern I call the multi-blocking pattern.

What is it and why is it needed
The multi-blocking pattern provides an interface by which you can create classes which with methods that are both non-blocking and blocking. This allows you to - for example - write simple AI routines, for example here is a really simple Clue AI routine.
1  
2  
3  
4  
5  
6  
7  
8  
9  
void aiTakeTurn () {
   evaluatePlans ();
   rollDice().complete();
   evaluateRange();
   moveToken().complete();
   suggest().complete();
   viewSuggestedCards();
   if ( isSureOfEvidence () ) accuse ();
}


Explanation of example

So what happened there? Well if your game is event driven and [say] running over a network then you end up splitting a particular routine over to the event handlers, or coming up with potentially flawed schemes to provide for linear coding. All that happens is that the model-control interface methods return a handle to the operation that is carried out, where complete will wait until the completion conditions are met.

Sure it's simple and isn't exactly going to cure cancerous code bloat, but it's got to be a useful approach to give to learner software engineers / computer scientists who are developing software that will probably have a need for both approaches. And it's a pattern with a name!

Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #1 - Posted 2007-08-10 22:23:59 »

I have a similair approach, using a ThreadPool (with 1 thread if I need queue-like behaviour).

1  
2  
3  
4  
5  
6  
7  
8  
9  
ThreadPool pool = new ThreadPool(1);
Task task = pool.addTask(new Runnable(){ ... });

task.waitFor();
task.waitFor(ms);

// or
pool.barrier();
pool.barrier(Runnable);


Implementing your interface with this backing would be easy, so although the approach is kinda different, under the hood it's probably all the same Smiley

To be honest, I think these async 'patterns' are pretty much implemented by anybody who has dealt with multi-threading in a non-trivial situation.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline broumbroum

Junior Devvie





« Reply #2 - Posted 2007-08-10 23:51:55 »

(...)
Explanation of example

So what happened there? Well if your game is event driven and [say] running over a network then you end up splitting a particular routine over to the event handlers, or coming up with potentially flawed schemes to provide for linear coding. All that happens is that the model-control interface methods return a handle to the operation that is carried out, where complete will wait until the completion conditions are met.

Sure it's simple and isn't exactly going to cure cancerous code bloat, but it's got to be a useful approach to give to learner software engineers / computer scientists who are developing software that will probably have a need for both approaches. And it's a pattern with a name!

Sorry, but I don't get to that "pattern" your explaining, though I'm used to usual forms of abstract models for Java. Hence I've got two questions:
-What's the very goal of that concept?
-Is it that you are facing a multi-threaded env. that you want to synch and gather the completed threads at once or do you want to describe something more abstract?

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mr_Light

Senior Devvie


Medals: 1


shiny.


« Reply #3 - Posted 2007-08-11 02:09:29 »

I have a similair approach, using a ThreadPool (with 1 thread if I need queue-like behaviour).

1  
2  
3  
4  
5  
6  
7  
8  
9  
ThreadPool pool = new ThreadPool(1);
Task task = pool.addTask(new Runnable(){ ... });

task.waitFor();
task.waitFor(ms);

// or
pool.barrier();
pool.barrier(Runnable);


Implementing your interface with this backing would be easy, so although the approach is kinda different, under the hood it's probably all the same Smiley

To be honest, I think these async 'patterns' are pretty much implemented by anybody who has dealt with multi-threading in a non-trivial situation.

1  
2  
3  
4  
5  
ExecutorService processor = Executors.newSingleThreadExecutor();
Future<?> future = processor.submit(new Callable<String>() {....});

future.get();
future.get(timeout, unit);

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-summary.html

and tbh I think the  termonoligy of the java api is most elegant, although get looks a bit wrong here. But if I care about if something is done or not I usually want to know how it completed.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline keldon85

Senior Devvie


Medals: 1



« Reply #4 - Posted 2007-08-11 07:29:36 »

Sorry, but I don't get to that "pattern" your explaining, though I'm used to usual forms of abstract models for Java. Hence I've got two questions:
-What's the very goal of that concept?
-Is it that you are facing a multi-threaded env. that you want to synch and gather the completed threads at once or do you want to describe something more abstract?

It's just for implementations where you want it to be able to work using both events, and linear coding. It's like getting user input, sometimes you just want to write n = getInput(), but you also want the system to work with just events for them. And yes it's in a multi-threaded environment where you may want to code linearly.

Riven's approach is about the same, which is why it is a pattern. We are achieving the same goal, and if there is a common approach to achieving a solution to the same problem then there is a design pattern others can use.

Offline keldon85

Senior Devvie


Medals: 1



« Reply #5 - Posted 2007-08-14 15:47:54 »

I've called the class JobTicket, let me know what you think? Sure it's nothing new thought wise, but it's a reusable class for beginners.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
87  
88  
89  
90  
91  
92  
93  
94  
95  
96  
97  
98  
99  
100  
101  
102  
103  
104  
105  
106  
107  
108  
109  
110  
111  
112  
113  
114  
115  
116  
117  
118  
/**
 * <p>
 *       A job ticket is a synchronisation object that can be used
 *       to issue jobs that may or not complete immediately. For example
 *       you may make a call to <b>clean a window</b>, the job may be performed
 *       immediately or may incur a delay.
 * </p>
 * <p>
 *       Depending on your implementation you may opt to create a
 *       solution where you respond to a job completion event, you may wish
 *       to wait for completion, or you may wish to do a bit of both. By using
 *       a JobTicket you can create an class method that is accessible by
 *       both approaches.
 * </p>
 * @author Keldon
 */

public class JobTicket {
   private State state;
   public enum State {
      INCOMPLETE, FINISHED, FAILED
   }
   
   /**
    * Creates a new JobTicket instance, and initialises the variables.
    * At this state the job is incomplete.
    */

   public JobTicket (){
      this.state = State.INCOMPLETE;
   }
   
   /**
    * returns the state of the JobTicket
    */

   public State getState (){
      return this.state;
   }
   
   /**
    * This method waits for the job to be completed. If it is already completed
    * then the method will return.
    */

   public JobTicket synchronise (){
      synchronized (this){
         // if the job is not completed then wait
         while (state == State.INCOMPLETE){
            try {
               wait();
            } catch (InterruptedException e) { }
         }
      }
     
      return this;
   }
   
   /**
    * Completes the job, any waiting threads in the synchronise method will
    * be notified, and any future calls to synchronise will not wait.
    */

   public JobTicket taskFinished (){
      synchronized (this) {
         this.state = State.FINISHED;
         notifyAll();
      }
     
      return this;
   }
   
   /**
    * Completes the job, any waiting threads in the synchronise method will
    * be notified, and any future calls to synchronise will not wait.
    */

   public JobTicket taskFailed (){
      synchronized (this) {
         this.state = State.FAILED;
         notifyAll();
      }
     
      return this;
   }
   
   /**
    * Demonstrates a JobTicket scenario with two cases. One case has the
    * job sleeping for a second and the synchronise call has to wait,
    * the second case has the job performed before synchronise is called.
    */

   public static void main (String argv[] ) throws InterruptedException {      
      final JobTicket printTicket1 = new JobTicket();
      final JobTicket printTicket2 = new JobTicket();
     
     
      Runnable job1 = new Runnable(){
         public void run() {
            try {
               Thread.sleep(1000);
            } catch (InterruptedException e) { }
           
            System.out.println ("Printing 1");
            printTicket1.taskFinished();
         }
      };
     
      Runnable job2 = new Runnable (){
         public void run () {
            System.out.println ("Printing 2");
            printTicket2.taskFinished();
         }
      };
     
      new Thread(job1).start();
      printTicket1.synchronise();
      System.out.println ("Ticket 1 done");
     
      new Thread(job2).start();
      Thread.sleep(1000);
      printTicket2.synchronise();
      System.out.println ("Ticket 2 done");
   }
}

Offline broumbroum

Junior Devvie





« Reply #6 - Posted 2007-08-14 22:18:27 »

class JobTicket demo above is good enough but will make a better synch if the wait() is replaced by the correct loop:
1  
2  
3  
4  
5  
6  
7  
8  
9  
synchronized(monitor) { 
   while(stateNotOK) {
       monitor.wait(10); // this timed wait is better to make sense of "Tickets", where the monitor can be replaced by the current instance a.k.a "this"
       System.out.println("Ticket waiting...");
   }
}
System.out.println("Ticket accepted.");
//(...)
     

BTW that's what I'd call a "multi-block pattern". Grin

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline Abuse

JGO Knight


Medals: 14


falling into the abyss of reality


« Reply #7 - Posted 2007-08-15 00:08:21 »

Seems like a very verbose way of implementing Thread.join() ?

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline broumbroum

Junior Devvie





« Reply #8 - Posted 2007-08-15 02:57:53 »

join() may behave the same way, as well.

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline keldon85

Senior Devvie


Medals: 1



« Reply #9 - Posted 2007-08-15 05:16:00 »

It does do a similar thing, but you get the added return status bonus. Although having said that maybe a state object implementing runnable that starts a thread would do that better. I'll look into that, because something like ReturnState.join() might actually make more sense.

And yes that is much more like ticket waiting behaviour, now you just need to add code simulating queue jumping and unnecessary delays Wink Having said that the classes implementation doesn't need a timed wait, but then again that while should be replaced with an if statement - it only had the while because I previously had it where you could change the state .... to INCOMPLETE. Then I replaced the changeState method with the ones there.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline JAW

Senior Devvie


Medals: 2



« Reply #10 - Posted 2007-09-19 13:12:56 »

Java has some stuff like Future and Task which actually allow return values for threaded objects which do not have the value right now but will have them at some point in the future. My experience is, when something is useful, it already exists. You just dont know how its called or where to search.

-JAW
Offline broumbroum

Junior Devvie





« Reply #11 - Posted 2007-09-19 18:35:00 »

on my knowledge I never have seen any programmatic language before Java that permits alike synch concepts. Now I can get a rendering-screen fully synchronized with such wait-for-thread patterns that are not available with PHP or Basic. This and other capabilities of Java have got many future consequences to new OS'es and virtual logic systems, for example faster AI and smarter robotics as well as robust softwares.  Cool

Since then I don't imagine that the Java programmers will take much more changes to the language architecture. Moreover programmers that are announcing new  "patterns or design concepts or even logical algorithms" may not be as far as they'd think so, technically meant. I'd say to practice more on your own to get more experience on Java programming and thereby announce that you discovered a new software application, not an unknown pattern or concept.... That sounds fuzzy... ( c'est dérisoire en français ) Roll Eyes

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline keldon85

Senior Devvie


Medals: 1



« Reply #12 - Posted 2007-09-19 19:53:50 »

Random thought: it takes little to create code that fulfils a particular requirement; but it takes great visionary to see the greater general use of an approach for others to follow... the way I write I should write books lol

Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #13 - Posted 2007-09-19 23:37:23 »

I really can't see what the fuzz is all about. When dealing with concurrency these are the first things you tend to do. It's not so much a pattern, it's simply the way to deal with threads. And then, it's not really that fancy, the first thing you learn in class is to let thread A wait for thread B until a condition is met, with some wait/notify constructs. As I pointed out earlier, it's much like a waitFor or a barrier: wait until thread A,B,C and D are done, then do something else. What is the pattern? It's simply *using* concurrency, not even in some clever way.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline keldon85

Senior Devvie


Medals: 1



« Reply #14 - Posted 2007-09-20 22:14:10 »

You sound upset, would you like a cup of tea Cool

Of course we learn to wait, notify, etc. although now you mention it what is "fancy" about any pattern exactly? Using typical thread behaviour is fine, but here it looked a little tidier, in the implementation. I was mainly using the class where my implementation could wait or use events, if you look at the code you can see that it doesn't necessarily need to invoke a thread. You can define an interface that returns the ticket, and the interface could be async or serial, you don't need to care, either respond to the message or wait.

You can write it in a more verbose way, but its a lot nicer when writing an interface (in some cases) where you can define your methods to perform methods whenever they feel like it, or straight away, where it will return a ticket that is already completed.

Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #15 - Posted 2007-09-21 05:35:58 »

<cup of tea mode>
Patterns are there to guide the programmer to program in a generally accepted way. A proven way to design things. What your code does is simply using basic functionality, not following a clearly defined way. As mentioned earlier, it behaves like Thread.join(), which also isn't a pattern in itself. That's why I'm a little agitated (maybe) because some people - especially broumbroum - are threating it as the next best thing, while there isn't much to it.
</cup of tea mode>


Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline keldon85

Senior Devvie


Medals: 1



« Reply #16 - Posted 2007-09-21 07:45:16 »

Nah, he says its like thread.join, and that it "sounds fuzzy". Probably pattern was the completely wrong word to use, but it really made the interface spec a lot nicer in my cluedo code where I could specify a function that could be implemented in either async or serial.

Having said that you could just as easily have the interface return a Thread to join, or run and wait for synchronization. Although with a ticket you only wait in a queue when the job isn't done. Nothing special really I guess, it's just covered up the decision underneath a little but as an example of what I was doing ...

You have moves like:
 - moveToken(position)
 - makeSuggestion (suggestion)
 - makeAccusation (suggestion)

And you have events like:
 - tokenMoved()
 - suggestionDisproofRequested()

With the ticket you can have the implementing players either sending messages and waiting for events, or  you could write your AI with simple methods like makeSuggestion ().complete() ... and then retrieve the card. Without that you have to explicitly involve threads and real synchronization. But if anything its just a good way of handling this type of behaviour in an interface, you can dress it up in many other ways too (naturally).

Maybe it was just my response to looking at second year uni work and thinking yuk, there is a problem. I liked the idea of an API that could work with thread-ignorant code but also thread-aware code too.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (29 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (42 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (50 views)
2014-12-03 16:27:13

CopyableCougar4 (47 views)
2014-11-29 21:32:03

toopeicgaming1999 (114 views)
2014-11-26 15:22:04

toopeicgaming1999 (102 views)
2014-11-26 15:20:36

toopeicgaming1999 (30 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!