In my technical documentation I have said:"Each entity is NOT a thread. Creating a thread for each entity is thread abuse; threads take up resources, while it is minimal for the first few threads it can quickly spiral into a performance disaster if not monitored. Better to have a good design than a sorry one."

While you're right in a real life level, this is a programming assignment designed to help people learn about threading. Maybe one of things people will get out of it is if they use a thread per fish then ramp the fish up to a 1000 the whole thing dies in a big heap, its a learning experience.

How many tutorials have you read online (including my own), where the example isn't really best practice? Its just a way of getting learners to try stuff, get results and understand.

The real problem is that you're way to ahead of what you're being taught. Try not to hassle the instructor/lecturer too much, its a hard life

Yeah, that scales REAL well, then.If the pupil gets curious (good thing) and start playing around with it and just increase FISH_COUNT (or whatever it is) to 100, he'll think java is the suckiest programming language in the world.

I also explained why naive threading in servers is a bad thing as well, btw. Scaling, scaling, scaling.

Meh, as I said above, maybe part of the point is letting students scale up with thread and see the problems. No better way to learn!

Plus, naive threading of any sort is a mistake, as in setting an arbitary number of threads as the limit where you should start worrying.

All I'm trying to say is its very easy to critisize an assignment when you have more knowledge (as this thread proves) than the target audience without seeing it from the eyes of a naive student or a teacher.

Sometimes the only way to learn something is troublesome is to run into the problems yourself.And, besides, I really can't think of a simple way of teaching threads without simplfying it to the point of it being "wrong".(Kinda like how teachers make students reinvent the wheel by implementing their own linked lists.)

So improper practices like these tend to give false perceptions of Java?

In this case, probably. But then I've seen threads taught like this in a variety of languages and its always going to give a bad impression since (as I think we've all agreed), its really not best practice.

Meh, as I said above, maybe part of the point is letting students scale up with thread and see the problems. No better way to learn!

In that case, the "good" lecturer would explicitly suggest that the students try ramping up to 1000 threads, and would then followup with an explanation (next tutorial, perhaps) of why it died AND have a tutorial outlining what you should do.

And if they don't have time to do that / don't want to cover it, the least they could do is add a note: "Although threads work well for a few fishes, this is not how threads are supposed to be used in general, and they wouldn't work properly with more than perhaps 10 fishes. The techniques for that are too advanced to cover here".

The whole point of this exercise is to teach good practice (OOP). Surely, to simultaneously teach bad practice is to undermine the core learning-objectives?

* blahblahblahh has had plenty of bad teachers in the past, as well as the good ones, and is fed up of the appallingly low quality of teaching some people get away with year after year.

There's no real excuse for bad teaching, e.g. if the teacher fails to spend even the 30 seconds it took me to type the above warning. Obviously, we don't have access to the follow-on assignments, but a moderately good teacher (not especially great, just "normal") would at least drop in the implication that too many fish was going to cause some fundamental problem that would be covered later.

PS: other than that, the assignment looks really good to me, much better than most undergrad examples of trying to teach OOP than I've seen (as a tutor).

The teacher that I don't know personally, have never been taught by, must be absolute rubbish because this single tutorial that he/she has set may be leaning toward a dodgy practice, that may or may not be illustrating the point, while trying to teach some at a very low level where it appears to be good form to manage to get your simple program running let alone worrying about the detail.

Teaching is hard - especially when you have students that surpass their expecting level.

As noted above, IMHO the example given is a particularly good OOP learning task (leaving aside where it falls down - but it falls down for want of less than 1 minute additional effort! Given how much effort it takes to put together a task like this, another minute is nothing), and the teacher should be respected for that.

But...too often, excuses are made for poor (usually either lazy or incompetent) teaching. Often there is no valid excuse: crap teachers should get another job, or else start putting more effort into their current job. Bad teaching screws up many people, and too often the poor teacher doesn't even care how bad their teaching is (seen this too many times first hand from teachers who condemn themselves out of their own mouths).

For a while I worked as an undergraduate tutor helping people who'd been taught badly at a wide variety of unis in the UK, and I used to be a classroom assistant in a local secondary school, so I have a basic grasp (very shallow) of the realities on the other side of the fence. Mostly, you gain an appreciation for how much effort it takes to put together teaching materials (a bit like writing documentation... ) - but that's exactly the same problem I face every day as a manager: it takes considerable time and effort to produce and regularly update schedules, documentation, project plans, progress reports, finance reports, business plans, etc. People don't say "X's project is 2 months behind schedule on a 4 month plan, he's overspent budget by a factor of 2, and all his staff keep resigining - but that's OK, because being a manager is hard", they say "X is utterly useless at management and should resign before he gets fired".

Of course, one of the *other* things that became increasingly clear the more time I spent around teachers and academic staff was the civil-service-esque unwillingness to actually fire anyone, ever.

"Each entity is NOT a thread. Creating a thread for each entity is thread abuse; threads take up resources, while it is minimal for the first few threads it can quickly spiral into a performance disaster if not monitored. Better to have a good design than a sorry one."

I STRONGLY suggest you do not refuse to do the assignment as the instructions state, and do not condescend to your professor/teacher. This is begging for trouble. Like mentioned before, he may very well have future assignments to tackle this problem (or he might not). But refusal to do as asked, and giving him a lecture at the same time might land you in some trouble in the class.

I would suggest that you do the assignment as requested by him and the instructions. THEN when turning it in (or the class soonest after), bring up the topic as a question. Let him discuss it, and teach. As said before, teaching people is hard, and the last thing he needs is a student coping an attitude with him.

Definitely comply with the hive mind of the classroom... if only during class time.

Take it from someone who has been marked down many times by teachers for jumping ahead of an assignment.

Not only that, but when you get your first asinine boss at work who will not listen to reason regarding proper programming techniques... you'll be able to grin when you say "Yes sir, may I have another?"

In my technical documentation I have said:"Each entity is NOT a thread. Creating a thread for each entity is thread abuse; threads take up resources, while it is minimal for the first few threads it can quickly spiral into a performance disaster if not monitored. Better to have a good design than a sorry one."

What do you guys think?

I don't think you should subvert the exercise purpose. The exercise is not suposed to teach you anything but to test your knowledge and mental gymnastics. You refuse to answer an exercise you get 0. Clean and simple.

As for "creating a thread for each entity is abuse" never give a loud answer in an exercise like this. Your teacher is not an idiot and you have much to learn with him. Even if they, sometimes, have some difficulty explaining things that are difficult to explain, they are usually more concerned in training your mind so that you can use it for yourself than giving you moral receipts on how to program. Allways remenber that you should allways do your own testings and don't go blindly with programming rules.

School assignments rarely have any grip on reality, but that's usually not the point anyway. Make the fishy program with threads, showing the teacher you know how to deal with them. The fact that threads aren't the... most efficient... way of modeling these fish doesn't matter for the assignment. The best you can do, and you can probably get extra credits for this, is to make a constructive remark in your documentation about it.

If you want to be really sneaky (welcome to office-level politics!), you can make it sound like you feel something is wrong, but don't know what exactly. Then, when you are discussing it with your teacher, ask him/her about it. Allow him/her to explain it. I'm assuming he/she actually knows what he/she is doing.... But actually that doesn't matter, just nod and sigh in agreement. If teachers hate anything, it's snotty students who know more than they do, so suck up to them for a higher grade. The sad thing is, if you do this correctly, it usually works. Only when doing projects where you have relative freedom of implementation, you should show that you know things... Oh, one more thing, teachers love design documents and implementation accounting more than the actual programming (Rightfully so, I might add, since for larger projects with more people, the building process becomes FAR FAR more important than the actual code crunching). Last thing: the teacher gives you the grade, you will only have to live with him/her for a few years, so you better be humble, even if the teacher has done nothing to deserve it. Because in the end, it doesn't matter if you were 'right', it matters what grade you get.

Marks will be awarded on the basis of your design, the program's correctness, clarity, use ofcomments, completeness and efficiency.

If the above is interpretted as the marking guide, then you should be ok designing your application as you see fit.

Although this scheme is contradicted by :-

Quote

The application shall provide:• A thread to represent each swimming fish.

Ofcourse, if you want to cover all your bases, you could implement both a single and multi-threaded version.You can then benchmark the 2 and show the lack of scalability the suggested design imposes upon the program.

Don't think of the assignment as a set task, instead think of it as an opportunity to demonstrate your development, and problem solving skills.

I'm sure Teachers get bored marking the same old Assignments over and over, they would much rather see some innovation and fresh ideas.

Because this off topic, allow me to drop a few comments: There's nothing wrong with the idea make each object having its own thread. Actually, this is a (obviously not so well know) programming paradigm invented by the programming language Actor in the late seventies.

Nowadays, Erlang is the most prominent language supporting 10.000 or 100.000 thread without problems. Another language I already mentioned here is Io. The website has a benchmark that shows that a webserver written in Io scales better than Apache httpd.

So, I think, there's nothing wrong with the assignment. It's only a problem of Java, that is nowadays always uses native threads which are a terse resource and which aren't that fast if you have thousands of context switches per second.

That's one gigabyte of wasted memory only for the per-thread stacks, not to mention that you've either got a lot of blocking IO (or other) operations going on, or a lot of thread-starving going on.

Either you know exactly what you're doing, or you're shooting yourself in the foot with an extremely elaborate gun. I can't tell which, since you didn't specify what your program does.

Simulation of a galaxy with 1000+ opponents with 3 mill + stars around each star is 4 - 24 planets, on each plenet could be armies of opponents, each army containing somewhat mill soldiers with detailed info about itself, each trying to kick the others' butt.

If these are independent operations that should finish in hopefully random order, then there is no starving aside some context switching penalty that would be here anyway.

There is a lot of simultaneous independed things so multiple threads are complete neccessity. Also majority of my previous research was tailored to multiple CPU computers, they appeared 5 years later than they should, so it wasn't much difficulty to let asynchronously cooperate that up to 1400 threads on windoze. Of course on normal computer there would be aproximately 140 threads running, the higher limit would be for computers with 64 GB RAM and at least some ability to address them. Luckily 64 bit computers are also becaming the norm.

It should work well with CPUs with 3 cores, and hopefully they'd add some processing subnodes, when 3 cores would be also too little. (It seems like they could setle on multiple nodes with 3 subnodes because communication between 3 cores is triangle, between 4 cores it would be tetrahedron. Of course if they would abandon purely 2D CPU concept they might go with 4 cores without problem... aside of the cooling one.) ~_^

That's one gigabyte of wasted memory only for the per-thread stacks, not to mention that you've either got a lot of blocking IO (or other) operations going on, or a lot of thread-starving going on.

Simulation of a galaxy with 1000+ opponents with 3 mill + stars around each star is 4 - 24 planets, on each plenet could be armies of opponents, each army containing somewhat mill soldiers with detailed info about itself, each trying to kick the others' butt.

Right, so you have a lot of data...

Quote

If these are independent operations that should finish in hopefully random order, then there is no starving aside some context switching penalty that would be here anyway.

That certainly does NOT rule out thread starvation...

Quote

There is a lot of simultaneous independed things so multiple threads are complete neccessity.

No. ONLY if these things literally must be simultaneous - i.e. they *must* run on different processors - which seems very very unlikely.

Quote

Of course on normal computer there would be aproximately 140 threads running, the higher limit would be for computers with 64 GB RAM and at least some ability to address them. Luckily 64 bit computers are also becaming the norm.

OK, so you have a big computer, but you're still wasting lots of performance unnecessarily, AFAICS.

Simulation of a galaxy with 1000+ opponents with 3 mill + stars around each star is 4 - 24 planets, on each plenet could be armies of opponents, each army containing somewhat mill soldiers with detailed info about itself, each trying to kick the others' butt.

The rest of the discussion aside (you seem to have put a lot of effort into it, so I won't say you're wrong. ), that seems like a very cool project. =DSupermassive. =D

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