"However, simultaneously one of the connections receives a timeout triggering a disconnection and removal from the user session. The connection locks itself"
Sets its "I am dead, don't ping me" flag, unlocks itself.
"and calls back the session object indicating an immediate dissociation. The dissociation indication causes the session the lock itself before removing the connection object from the list of connections.
The user request and the timeout take place in separate threads. With the right"
locking strategy, a deadlock is avoided.
Sorry, I've begun to sound both confrontational and smug (in my head) and that's not how I wanted to come across. Sure, there are things to think about when going with threaded solutions, and situations to avoid that a novice thread programmer may miss. In many cases though it's just making sure that locks aren't held for a moment more than necessary and that state information is maintained.
Yes, and your hypothetical design has it wrong. Encapsulation is perfectly possible in a multithreaded world. I'm a C programmer and it's fairly trivial to make thread safe APIs. I don't quite get your A and B example, could you make it more explicit? Are they both trying to access the same resource? in which case the synchronisation ought to take place at the resource level.
"It's true that battle-hardened multithreaders offer thread pools as an antidote to some of the woes of multithreading."
I'm not proposing it as a solution to the supposed "woes" of multithreading. There aren't any in my experience, once you've learned the ropes. I'm proposing it as a parallelised (and superior) way to acheive the same results as your asynchronous event driven programming. It uses many of the same techniques (async io, polling, signals etc etc) but also scales effortlessly in ways that the async event-driven single threaded app cannot. They don't only solve the problem of thread proliferation, they solve the problem of utilising multiple hardware threads/processors/cores transparently and without needing to refactor your whole design. They also don't suffer from the complexities surrounding full IPC in terms of shared memory.
"The 15 year old hotshot response would be more like, "woohoo, I get to play with threads!""
Funny you should say that. My first job out of university, six months into it they handed me control of a brand new middle tier project that was a big part of the company's future (yeah, there was something wrong with them). And my first reaction was...
You simply build scalability into the app from the word go. If you're really clever you can build in some tunable parameters, like the size of a thread pool, and have your app make good use of whatever's available.
"The single-threaded, event-driven architecture allows the server itself to remain relatively lightweight. "
Which, if that's what you want, then it's a good thing. If, on the other hand, you want to make full and efficient use of the platform you're on (and the keyword is *full*) then you do things a little differently, especially where multiple cores are available.
"E.g., let's say we write a massively multi-threaded shooter game. Each player is a separate thread,"
Well there's your first mistake. That's a recipe for disaster and built in limits to the number of players.
Ideally you seperate up your server app into multiple discrete jobs and process them with a thread pool. I don't know how well that maps to gaming but many server apps work very well with that paradigm.
But not all. And there is a beautiful (IMHO) compromise.
"First, they give the developer an illusion simplicity in the beginning of development. Each thread minds its own business and inevitably follows its state machine that is plainly visible as a sequential program: receive this, compute that, save the result, send the response, repeat from beginning."
Yes, they do. they also make sense in many ways as a natural actor-driven state of affairs. Client A opens comms with the middle tier, middle tier spawns a thread that deals with client A and it's requests to underlying data sources. Client B connects, spawn another thread etc etc. It encapsulates things quite well. Not that this is a good way of doing things, but more on that later.
Windows does support the whole async io thing now, as far as I'm aware, but that was an issue on some of the earlir windows platforms.
"I've had my share of trying to sew together the multithreaded solutions of less timid developers."
I can certainly appreciate that. Finding meaning in large chunks of other people's code is tricky at the best of times. Add in a good measure of incompetence and a shake of threading, you have a recipe for incomprehensibility. Solution - hire decent staff.
"Locking is missing and cannot be added without deadlocks. It is also virtually impossible to find all places in the code where locking is missing and where it needs to be added."
Design, intelligence and good practice. As with your deadlock example, there are good ways around these situations and they tend to involve a bit of forethought. A needs to lock B and B needs to lock A? Why? Something is probably wrong with your design.
"The second big problem with multithreading is that the threading paradigm requires only one input at a time (after all, multiplexing was not allowed)."
This is not necessarily true. I'm a C programmer and have found that io multiplexing and threads can go hand in hand very nicely. The multiplexing is just a necessary part of writing a capable server or middle tier, and threading provides (when done well) effortless scalability.
"At a bare minimum if a thread is waiting on a socket, it must be receptive to another thread telling it to stop waiting because of a change in circumstances"
There are various interrupt mechanisms availble, or one can have a message pipe that a thread polls along with the socket. This is a bit messy but doesn't require periodic polling or anything else so inefficient.
"It follows that experienced developers generally prefer the single-threaded, event-driven paradigm"
Remove the word "single-threaded" from that and I agree. One of the best solutions (IMHO) for a scalable and yet robust system is the thread pool. You have a manager thread that is responsible for polling various file descriptors and timers, you have a variety of job queues, and you have a pool of threads that take jobs off the queue and run them. You then implement the rest of the program as a series of discrete jobs that (ideally) never block. then you can tune the size of your pool based to get the best out of the machine you're running on.
Multi process apps have been common in the business and server app space for almost two decades. Multi thread apps have been common in the business and server world for a few years now too.
To all having the will it/won't it go mainstream argument: You missed the boat. It's mainstream.
Though you say "they're not using a parallel programming language appropriate for their target."
I think too much emphasis is put, by some, on using a high level language that is specifically designed for parallelism. Personally I've always found C and POSIX threads more than adequate.
They'll allow you to use threads most happily and not take you too far away from the hardware.
The fact that you actually have to think a bit more about who's accessing what data at what time, and avoid trvial problems like deadlock, does not make it "too hard". And the fact that C is not ideal for parallelising mathematical operations doesn't make it useless either. Threads can be doing totally different things, or be pooled for great joy.
Been using multithread and/or multiprocess programming my whole career (about 8 years now). I don't know if it generalises to the whole of the US but I'm always astounded at the attitude of people on slashdot to parallel programming.
We hear over and over again "it's not goping to go mainstream", "it's hard to get right", "threads are a recipe for disaster", "synchronisation is just too much work to debug", "it's a niche area" etc etc
Even occasionally "It'll never take off".
Well, guys, it has. A lot of people, software houses from several employess to several thousand employees, have been using parallelism in commercial settings for a long time now. And we're already making use of the extra resources available in multicore platforms without having to do a single thing to our codebases.
Slashdot's usually pretty cutting edge in it's tech (and esspiallcy language) evangelism, why has it slacked on this one?
Well, i have the static IP and rDNS, but not the non-residential service level. My ISP is just a home ISP, though a geek-friendly one (static IPs available, "up to 24Mb") and whilst they claim to block port 25 and mandate relay via their servers, they don't actually seem to do it.
To be honest, the only folks I've had a problem with are hotmail, and I'm not that bothered. I don't interact with hotmail users all that much.
Nah, I get the reasons why people do it, I'm more just disappointed that it's become necessary.
"It is they who should have the blame for mail servers being configured as fortresses. It is all the mail admins can do to keep on top of their shenanigans."
Oh I agree entirely, I'm not going to blame the mail admins. Like many other things in this life, it's just depressing that we humans have to prove over and over again that we can't play together nicely without some small group of determined assholes ruining it for everyone.
As an small scale admin myself, it was a pain having to get spamhaus xbl and various other countermeasures setup. My mailserver can't cope with much, being based on an ARM 266 processor.
Blocking known residential blocks sucks as a solution as it removes some of the democracy of the net.
I (like others I'm sure, but maybe not so many of us these days) run a mail/web server from home. I just use it for personal mail. I have SPF and rDNS set up, I play by all the rules. Why block me because I use ADSL at home with a static IP ?
Whilst I appreciate that accepting mail from my IP is potentially a higher risk factor, blocking all residential blocks sems to me to be overkill.
People do have private planes here in the UK, it's just not that common. Probably because it's very expensive and our Nanny State government think it's dangerous and to be discouraged.
I'd be really really really really really surprised and shocked if they were using any form of tech that went over the internet or even shared the first mile with it. They either use a phoneline (plenty fast for a coffee shop, if it's always on), ISDN or some other form of leased private line.
I'm not saying for a moment I don't appreciate our testers, I work quite closely with them - generally giving them the heads up on what we're doing so they can get their tests designed ahead of time - I'm just saying I don't find the prospect of doing their work thrilling.
You may be onto something with design of auto test frameworks and the like, but I have a feeling even that could be repetetive. If you have the freedom and expertise to get creative in the security test arena that could be fun, input fuzzing and the like...
I'm not saying for a moment I don't appreciate our testers,I work quite closely with them - generally giving them the heads up on what we're doing so they can get their tests designed ahead of time - I'm just saying i don't find the prospect thrilling.
You may be onton something with design of auto test frameworks and the like, but I have a feeling even that could be competetive. If you have the freedom and expertise to get creative in the security test arena that could be fun, fuzzing and the like...
To be fair, in most places testers test exactly what they are commanded to test by their masters too. There's none of us have a huge amount of freedom in this corporate world.
Oh, and from the dev perspective - sure, you can tell us what you want it to do. The internals will be a poetry and a mechanical masterpiece all of my own that the masters don't have a hope in hell of understanding.
I think this is very much an "each to their own" thing. Perhaps I have overlooked the attractions of test analysis/design. To me it will always be the tedious bit that happens between us finishing the software and itt going out the door. But then I work in a *very* low bug team.
But who the hell would want to do that for a job? Honestly....
I found out our testers are payed on a par with or more than software developers the other day. At first I was a little angry, because I get angry whenever anyone is paid more than software developers because "we make your fscking products!".
Then I thought "What would it take to get me into that job?" and I realised they were welcome to the money.
Slashdot Mirror
"However, simultaneously one of the connections receives a timeout triggering a disconnection and removal from the user session. The connection locks itself"
Sets its "I am dead, don't ping me" flag, unlocks itself.
"and calls back the session object indicating an immediate dissociation. The dissociation indication causes the session the lock itself before removing the connection object from the list of connections.
The user request and the timeout take place in separate threads. With the right"
locking strategy, a deadlock is avoided.
Sorry, I've begun to sound both confrontational and smug (in my head) and that's not how I wanted to come across. Sure, there are things to think about when going with threaded solutions, and situations to avoid that a novice thread programmer may miss. In many cases though it's just making sure that locks aren't held for a moment more than necessary and that state information is maintained.
"It's called encapsulation."
Yes, and your hypothetical design has it wrong. Encapsulation is perfectly possible in a multithreaded world. I'm a C programmer and it's fairly trivial to make thread safe APIs. I don't quite get your A and B example, could you make it more explicit? Are they both trying to access the same resource? in which case the synchronisation ought to take place at the resource level.
"It's true that battle-hardened multithreaders offer thread pools as an antidote to some of the woes of multithreading."
I'm not proposing it as a solution to the supposed "woes" of multithreading. There aren't any in my experience, once you've learned the ropes. I'm proposing it as a parallelised (and superior) way to acheive the same results as your asynchronous event driven programming. It uses many of the same techniques (async io, polling, signals etc etc) but also scales effortlessly in ways that the async event-driven single threaded app cannot. They don't only solve the problem of thread proliferation, they solve the problem of utilising multiple hardware threads/processors/cores transparently and without needing to refactor your whole design. They also don't suffer from the complexities surrounding full IPC in terms of shared memory.
That's very true.
"The 15 year old hotshot response would be more like, "woohoo, I get to play with threads!""
Funny you should say that. My first job out of university, six months into it they handed me control of a brand new middle tier project that was a big part of the company's future (yeah, there was something wrong with them). And my first reaction was...
God what a mess. Still, it worked. Mostly.
You simply build scalability into the app from the word go. If you're really clever you can build in some tunable parameters, like the size of a thread pool, and have your app make good use of whatever's available.
"Anything harder than a problem needs to be is too hard."
Agreed 100%
"The question is whether concurrency can be made easier while preserving the benefits it provides."
It's not difficult now. People just have a weird mental block about it. Sure, it's a different way of thinking, but it really isn't that tough.
Or maybe I'm just some sort of programming god. No, no, I think it's more likely that people just have weird ideas about how hard it is.
"The single-threaded, event-driven architecture allows the server itself to remain relatively lightweight. "
Which, if that's what you want, then it's a good thing. If, on the other hand, you want to make full and efficient use of the platform you're on (and the keyword is *full*) then you do things a little differently, especially where multiple cores are available.
"E.g., let's say we write a massively multi-threaded shooter game. Each player is a separate thread,"
Well there's your first mistake.
That's a recipe for disaster and built in limits to the number of players.
Ideally you seperate up your server app into multiple discrete jobs and process them with a thread pool. I don't know how well that maps to gaming but many server apps work very well with that paradigm.
True, but it scales well, you can have multiple child instances in the same nine months by throwing more women at the problem.
But not all. And there is a beautiful (IMHO) compromise.
"First, they give the developer an illusion simplicity in the beginning of development. Each thread minds its own business and inevitably follows its state machine that is plainly visible as a sequential program: receive this, compute that, save the result, send the response, repeat from beginning."
Yes, they do. they also make sense in many ways as a natural actor-driven state of affairs. Client A opens comms with the middle tier, middle tier spawns a thread that deals with client A and it's requests to underlying data sources. Client B connects, spawn another thread etc etc. It encapsulates things quite well. Not that this is a good way of doing things, but more on that later.
Windows does support the whole async io thing now, as far as I'm aware, but that was an issue on some of the earlir windows platforms.
"I've had my share of trying to sew together the multithreaded solutions of less timid developers."
I can certainly appreciate that. Finding meaning in large chunks of other people's code is tricky at the best of times. Add in a good measure of incompetence and a shake of threading, you have a recipe for incomprehensibility. Solution - hire decent staff.
"Locking is missing and cannot be added without deadlocks. It is also virtually impossible to find all places in the code where locking is missing and where it needs to be added."
Design, intelligence and good practice. As with your deadlock example, there are good ways around these situations and they tend to involve a bit of forethought. A needs to lock B and B needs to lock A? Why? Something is probably wrong with your design.
"The second big problem with multithreading is that the threading paradigm requires only one input at a time (after all, multiplexing was not allowed)."
This is not necessarily true. I'm a C programmer and have found that io multiplexing and threads can go hand in hand very nicely. The multiplexing is just a necessary part of writing a capable server or middle tier, and threading provides (when done well) effortless scalability.
"At a bare minimum if a thread is waiting on a socket, it must be receptive to another thread telling it to stop waiting because of a change in circumstances"
There are various interrupt mechanisms availble, or one can have a message pipe that a thread polls along with the socket. This is a bit messy but doesn't require periodic polling or anything else so inefficient.
"It follows that experienced developers generally prefer the single-threaded, event-driven paradigm"
Remove the word "single-threaded" from that and I agree. One of the best solutions (IMHO) for a scalable and yet robust system is the thread pool. You have a manager thread that is responsible for polling various file descriptors and timers, you have a variety of job queues, and you have a pool of threads that take jobs off the queue and run them. You then implement the rest of the program as a series of discrete jobs that (ideally) never block. then you can tune the size of your pool based to get the best out of the machine you're running on.
You just haven't noticed.
Multi process apps have been common in the business and server app space for almost two decades.
Multi thread apps have been common in the business and server world for a few years now too.
To all having the will it/won't it go mainstream argument: You missed the boat. It's mainstream.
Though you say "they're not using a parallel programming language appropriate for their target."
I think too much emphasis is put, by some, on using a high level language that is specifically designed for parallelism. Personally I've always found C and POSIX threads more than adequate.
They'll allow you to use threads most happily and not take you too far away from the hardware.
The fact that you actually have to think a bit more about who's accessing what data at what time, and avoid trvial problems like deadlock, does not make it "too hard". And the fact that C is not ideal for parallelising mathematical operations doesn't make it useless either. Threads can be doing totally different things, or be pooled for great joy.
Hey, I'm a "Dumbed-down, corporatized C coder" and I've been working on threaded, parallel and distributed systems for the last 8 years!
Maybe I'm not that dumbed down, but we are out there and I don't think I'm particularly special...
... with C. Then you can't avoid knowing what's going on under the covers.
It's not that tough, really.
Been using multithread and/or multiprocess programming my whole career (about 8 years now). I don't know if it generalises to the whole of the US but I'm always astounded at the attitude of people on slashdot to parallel programming.
We hear over and over again "it's not goping to go mainstream", "it's hard to get right", "threads are a recipe for disaster", "synchronisation is just too much work to debug", "it's a niche area" etc etc
Even occasionally "It'll never take off".
Well, guys, it has. A lot of people, software houses from several employess to several thousand employees, have been using parallelism in commercial settings for a long time now. And we're already making use of the extra resources available in multicore platforms without having to do a single thing to our codebases.
Slashdot's usually pretty cutting edge in it's tech (and esspiallcy language) evangelism, why has it slacked on this one?
Well, i have the static IP and rDNS, but not the non-residential service level. My ISP is just a home ISP, though a geek-friendly one (static IPs available, "up to 24Mb") and whilst they claim to block port 25 and mandate relay via their servers, they don't actually seem to do it.
To be honest, the only folks I've had a problem with are hotmail, and I'm not that bothered. I don't interact with hotmail users all that much.
Nah, I get the reasons why people do it, I'm more just disappointed that it's become necessary.
"It is they who should have the blame for mail servers being configured as fortresses. It is all the mail admins can do to keep on top of their shenanigans."
Oh I agree entirely, I'm not going to blame the mail admins.
Like many other things in this life, it's just depressing that we humans have to prove over and over again that we can't play together nicely without some small group of determined assholes ruining it for everyone.
As an small scale admin myself, it was a pain having to get spamhaus xbl and various other countermeasures setup. My mailserver can't cope with much, being based on an ARM 266 processor.
Blocking known residential blocks sucks as a solution as it removes some of the democracy of the net.
I (like others I'm sure, but maybe not so many of us these days) run a mail/web server from home. I just use it for personal mail. I have SPF and rDNS set up, I play by all the rules. Why block me because I use ADSL at home with a static IP ?
Whilst I appreciate that accepting mail from my IP is potentially a higher risk factor, blocking all residential blocks sems to me to be overkill.
People do have private planes here in the UK, it's just not that common. Probably because it's very expensive and our Nanny State government think it's dangerous and to be discouraged.
I'd be really really really really really surprised and shocked if they were using any form of tech that went over the internet or even shared the first mile with it. They either use a phoneline (plenty fast for a coffee shop, if it's always on), ISDN or some other form of leased private line.
Here's the post again, without the typos:
I'm not saying for a moment I don't appreciate our testers, I work quite closely with them - generally giving them the heads up on what we're doing so they can get their tests designed ahead of time - I'm just saying I don't find the prospect of doing their work thrilling.
You may be onto something with design of auto test frameworks and the like, but I have a feeling even that could be repetetive. If you have the freedom and expertise to get creative in the security test arena that could be fun, input fuzzing and the like...
I'm not saying for a moment I don't appreciate our testers,I work quite closely with them - generally giving them the heads up on what we're doing so they can get their tests designed ahead of time - I'm just saying i don't find the prospect thrilling.
You may be onton something with design of auto test frameworks and the like, but I have a feeling even that could be competetive. If you have the freedom and expertise to get creative in the security test arena that could be fun, fuzzing and the like...
I'll stick to dev.
To be fair, in most places testers test exactly what they are commanded to test by their masters too. There's none of us have a huge amount of freedom in this corporate world.
Oh, and from the dev perspective - sure, you can tell us what you want it to do. The internals will be a poetry and a mechanical masterpiece all of my own that the masters don't have a hope in hell of understanding.
I think this is very much an "each to their own" thing. Perhaps I have overlooked the attractions of test analysis/design. To me it will always be the tedious bit that happens between us finishing the software and itt going out the door. But then I work in a *very* low bug team.
But who the hell would want to do that for a job? Honestly....
I found out our testers are payed on a par with or more than software developers the other day. At first I was a little angry, because I get angry whenever anyone is paid more than software developers because "we make your fscking products!".
Then I thought "What would it take to get me into that job?" and I realised they were welcome to the money.
Did you even read that page? There's no confirmation there even is a "Mars Effect" let alone an explanation that favours astrology.