hmmmmm.... should I write my first article
-
The subject came up again today at work over parallel programming. Others here have encouraged me to write an article, and although I have argued against it because of the difficult with work. I am tired of having to explain the concepts over and over again one person at a time. The question is, do I do it as an internal white paper only (all the writing, none of the review) only for people at work, or do I write for public access as well? So are there already too many articles on threading? I have rarely seen people talk about atomic operations, massively parallel, cooperatively asynchronous operation, and lock-free programming. But the better question is, does anyone really care? I can easily do it internal only for my team, and maybe other teams at other similar facilities, but if the subject is really desirable, maybe it needs to be wider?
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
So are there already too many articles on threading?
Heck no! It's eventually going to be the one of the hottest issues in computing. If you were going to write it for your team anyway, what would be the harm in letting us read it also?
-------------------------------- "All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke
-
Jeffry J. Brickley wrote:
So are there already too many articles on threading?
Heck no! It's eventually going to be the one of the hottest issues in computing. If you were going to write it for your team anyway, what would be the harm in letting us read it also?
-------------------------------- "All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke
Richie308 wrote:
what would be the harm in letting us read it also?
It has to pass through the company approval process, as well as other approval processes before it ever gets to CP, even if I write it at home. Writing it for work only, means none of the approval is necessary, just optional. Writing it for CP means I can release it internally and then go through the slower approval and editing for external release. It's more effort basically. But if it is something that is desired, I could probably break it into a series, it's a complex issue. Atomic Parallelization: all of the power of parallel, none of the WMD.... ;P
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
The subject came up again today at work over parallel programming. Others here have encouraged me to write an article, and although I have argued against it because of the difficult with work. I am tired of having to explain the concepts over and over again one person at a time. The question is, do I do it as an internal white paper only (all the writing, none of the review) only for people at work, or do I write for public access as well? So are there already too many articles on threading? I have rarely seen people talk about atomic operations, massively parallel, cooperatively asynchronous operation, and lock-free programming. But the better question is, does anyone really care? I can easily do it internal only for my team, and maybe other teams at other similar facilities, but if the subject is really desirable, maybe it needs to be wider?
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
The subject came up again today at work over parallel programming. Others here have encouraged me to write an article, and although I have argued against it because of the difficult with work. I am tired of having to explain the concepts over and over again one person at a time. The question is, do I do it as an internal white paper only (all the writing, none of the review) only for people at work, or do I write for public access as well? So are there already too many articles on threading? I have rarely seen people talk about atomic operations, massively parallel, cooperatively asynchronous operation, and lock-free programming. But the better question is, does anyone really care? I can easily do it internal only for my team, and maybe other teams at other similar facilities, but if the subject is really desirable, maybe it needs to be wider?
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
So are there already too many articles on threading?
Yes. But there are too few good ones. So, if you can avoid the "threading is hard, here's how you cheat" / "this is a bit tricky - so i'll leave it as an exercise for the reader" / "I wrote the damn scheduler, and don't understand why you lot can't get the hang of it" traps, i'd certainly love to read it! :D
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
Jeffry J. Brickley wrote:
So are there already too many articles on threading?
Yes. But there are too few good ones. So, if you can avoid the "threading is hard, here's how you cheat" / "this is a bit tricky - so i'll leave it as an exercise for the reader" / "I wrote the damn scheduler, and don't understand why you lot can't get the hang of it" traps, i'd certainly love to read it! :D
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
Shog9 wrote:
But there are too few good ones.
Well, I don't know if I would right write a good one... What is it the good/bad programmer thread said? It can always be better. :) (obviously that was a self-predictive statement) -- modified at 0:49 Tuesday 6th February, 2007
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Shog9 wrote:
But there are too few good ones.
Well, I don't know if I would right write a good one... What is it the good/bad programmer thread said? It can always be better. :) (obviously that was a self-predictive statement) -- modified at 0:49 Tuesday 6th February, 2007
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Jeffry J. Brickley wrote:
I would right a good one
As long as you have a spell checker you'll be fine! ;)
John Cardinal wrote:
As long as you have a spell checker you'll be fine!
A spell checker wouldn't help there, right and write are both correct spelling... I actually need to hire my own tech writer... oh wait... work has one for me if I write it internally first. ;)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
John Cardinal wrote:
As long as you have a spell checker you'll be fine!
A spell checker wouldn't help there, right and write are both correct spelling... I actually need to hire my own tech writer... oh wait... work has one for me if I write it internally first. ;)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Sure, go ahead; would save me the effort of coming over and ask you to explain it to me in person.:-D You also might miss the chance of a second career, if you don't.
prepare that the light at the end of the tunnel is just a freight train coming your way - metallica
-
The subject came up again today at work over parallel programming. Others here have encouraged me to write an article, and although I have argued against it because of the difficult with work. I am tired of having to explain the concepts over and over again one person at a time. The question is, do I do it as an internal white paper only (all the writing, none of the review) only for people at work, or do I write for public access as well? So are there already too many articles on threading? I have rarely seen people talk about atomic operations, massively parallel, cooperatively asynchronous operation, and lock-free programming. But the better question is, does anyone really care? I can easily do it internal only for my team, and maybe other teams at other similar facilities, but if the subject is really desirable, maybe it needs to be wider?
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
The subject came up again today at work over parallel programming. Others here have encouraged me to write an article, and although I have argued against it because of the difficult with work. I am tired of having to explain the concepts over and over again one person at a time. The question is, do I do it as an internal white paper only (all the writing, none of the review) only for people at work, or do I write for public access as well? So are there already too many articles on threading? I have rarely seen people talk about atomic operations, massively parallel, cooperatively asynchronous operation, and lock-free programming. But the better question is, does anyone really care? I can easily do it internal only for my team, and maybe other teams at other similar facilities, but if the subject is really desirable, maybe it needs to be wider?
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
The subject came up again today at work over parallel programming. Others here have encouraged me to write an article, and although I have argued against it because of the difficult with work. I am tired of having to explain the concepts over and over again one person at a time. The question is, do I do it as an internal white paper only (all the writing, none of the review) only for people at work, or do I write for public access as well? So are there already too many articles on threading? I have rarely seen people talk about atomic operations, massively parallel, cooperatively asynchronous operation, and lock-free programming. But the better question is, does anyone really care? I can easily do it internal only for my team, and maybe other teams at other similar facilities, but if the subject is really desirable, maybe it needs to be wider?
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
does anyone really care?
Yes, we care! If there are some easy practical examples, the better! jhaga
It would be glorious to see mankind at leisure for once. It is nothing but work, work, work. I cannot easily buy a blank-book to write thoughts in; they are commonly ruled for dollars and cents. A[man], seeing me making a minute in the fields, took it for granted that I was calculating my wages. — business! - I think that there is nothing, not even crime, more opposed to poetry, to philosophy, ay, to life itself, than this incessant business. Henry David Thoreau
-
That sounds like a really enjoyable read.
Brad Australian - Christian Graus on "Best books for VBscript" A big thick one, so you can whack yourself on the head with it.
Hi Did you get a chance to finish the software protection thing you were doing a while ago? Chandra
-
Hi Did you get a chance to finish the software protection thing you were doing a while ago? Chandra
-
The subject came up again today at work over parallel programming. Others here have encouraged me to write an article, and although I have argued against it because of the difficult with work. I am tired of having to explain the concepts over and over again one person at a time. The question is, do I do it as an internal white paper only (all the writing, none of the review) only for people at work, or do I write for public access as well? So are there already too many articles on threading? I have rarely seen people talk about atomic operations, massively parallel, cooperatively asynchronous operation, and lock-free programming. But the better question is, does anyone really care? I can easily do it internal only for my team, and maybe other teams at other similar facilities, but if the subject is really desirable, maybe it needs to be wider?
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
We need it. trust me on this.
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
That copyright protection thing?
Brad Australian - Christian Graus on "Best books for VBscript" A big thick one, so you can whack yourself on the head with it.
No, you were looking for ways to limit to only one active copy of the software at anytime... we were suggesting hardware locks and some vendors of software keys. You had also mentioned that you had some pseudo worked out, which I am (still) very much interested in :)
-
The subject came up again today at work over parallel programming. Others here have encouraged me to write an article, and although I have argued against it because of the difficult with work. I am tired of having to explain the concepts over and over again one person at a time. The question is, do I do it as an internal white paper only (all the writing, none of the review) only for people at work, or do I write for public access as well? So are there already too many articles on threading? I have rarely seen people talk about atomic operations, massively parallel, cooperatively asynchronous operation, and lock-free programming. But the better question is, does anyone really care? I can easily do it internal only for my team, and maybe other teams at other similar facilities, but if the subject is really desirable, maybe it needs to be wider?
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
I'd read it too. :)
-
No, you were looking for ways to limit to only one active copy of the software at anytime... we were suggesting hardware locks and some vendors of software keys. You had also mentioned that you had some pseudo worked out, which I am (still) very much interested in :)
Oh yes, that was indeed for copyright restrictions. There is only one bug left in the lgic, once i have covered that i will start getting it ready for coding.
Brad Australian - Christian Graus on "Best books for VBscript" A big thick one, so you can whack yourself on the head with it.
-
The subject came up again today at work over parallel programming. Others here have encouraged me to write an article, and although I have argued against it because of the difficult with work. I am tired of having to explain the concepts over and over again one person at a time. The question is, do I do it as an internal white paper only (all the writing, none of the review) only for people at work, or do I write for public access as well? So are there already too many articles on threading? I have rarely seen people talk about atomic operations, massively parallel, cooperatively asynchronous operation, and lock-free programming. But the better question is, does anyone really care? I can easily do it internal only for my team, and maybe other teams at other similar facilities, but if the subject is really desirable, maybe it needs to be wider?
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Richie308 wrote:
what would be the harm in letting us read it also?
It has to pass through the company approval process, as well as other approval processes before it ever gets to CP, even if I write it at home. Writing it for work only, means none of the approval is necessary, just optional. Writing it for CP means I can release it internally and then go through the slower approval and editing for external release. It's more effort basically. But if it is something that is desired, I could probably break it into a series, it's a complex issue. Atomic Parallelization: all of the power of parallel, none of the WMD.... ;P
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
If you write it at home in your spare time you are not allowed to post it on CP?!? :confused:
-
The subject came up again today at work over parallel programming. Others here have encouraged me to write an article, and although I have argued against it because of the difficult with work. I am tired of having to explain the concepts over and over again one person at a time. The question is, do I do it as an internal white paper only (all the writing, none of the review) only for people at work, or do I write for public access as well? So are there already too many articles on threading? I have rarely seen people talk about atomic operations, massively parallel, cooperatively asynchronous operation, and lock-free programming. But the better question is, does anyone really care? I can easily do it internal only for my team, and maybe other teams at other similar facilities, but if the subject is really desirable, maybe it needs to be wider?
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Jeffry J. Brickley wrote:
So are there already too many articles on threading?
Threading is different than parallel programming.
Jeffry J. Brickley wrote:
But the better question is, does anyone really care?
I would, and I think it's where programming needs to head.
Jeffry J. Brickley wrote:
but if the subject is really desirable, maybe it needs to be wider?
I'd love to see an article on the subject! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith
