|
|
|
|
|
|
| Author |
Message |
Nick Roberts
*nix forums beginner
Joined: 12 Feb 2006
Posts: 5
|
 Posted: Mon Feb 13, 2006 3:31 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
Maxim S. Shatskih wrote:
| Quote: | Please note where and when the Win32 APIs are not thread-safe.
|
Maxim, I get the impression that you know a lot about the Win32 API, so
I'm surprised by your question. Note that I have been familiar with the
Win32 API from the earliest days of Windows, and I have studied their
design in detail. (In truth, I've forgotten most of what I used to know,
it was such a long time ago.)
The problem is essentially with the Microsoft documentation, which has
always been ludicrously inadequate, not least in the area of
multi-threaded programming. It would take me a very long time to give a
comprehensive list of these inadequacies, but let me give just one,
entirely typical example.
When a thread of a Windows program calls the Win32 API function
CreateWindow (or CreateWindowEx), a handle is returned to the created
window. This handle is used for all subsequent interaction with the
window via the Windows API.
For a long time (several years, I recall), people were trying to do
window operations using a multi-threaded program and wondering why it
didn't work. Eventually, Microsoft came clean, and admitted that only
the thread that created the window could subsequently manipulate that
window (in particular, only that thread can receive messages from the
window). For this reason (together with the fact that Unix doesn't
support threading at all), most Windows programs remain single-threaded;
programmers acquired the impression that multi-threading under Windows
was such a black art it wasn't worth the effort.
--
Nick Roberts |
|
| Back to top |
|
 |
Maxim S. Shatskih
*nix forums addict
Joined: 02 Apr 2005
Posts: 55
|
| Posted: Mon Feb 13, 2006 5:12 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
| Quote: | Please note where and when the Win32 APIs are not thread-safe.
Maxim, I get the impression that you know a lot about the Win32 API, so
I'm surprised by your question.
|
I'm surprised by your answer. Can you _name the exact Win32 API routines by
Microsoft_ which do not support multithreading?
| Quote: | When a thread of a Windows program calls the Win32 API function
CreateWindow (or CreateWindowEx), a handle is returned to the created
window. This handle is used for all subsequent interaction with the
window via the Windows API.
|
HWND belongs to a thread. IIRC it is well-described in lots of places, and is a
well known fact in Windows world.
| Quote: | didn't work. Eventually, Microsoft came clean, and admitted that only
the thread that created the window could subsequently manipulate that
window (in particular, only that thread can receive messages from the
window).
|
There is no such things like "messages from the window" in Windows. Messages TO
the window" - yes, a reality.
Several years? What several years? The adequate professionals knew this in
around 1996, which is 1 year after the desktop Windows version (Win95)
supported multi-threading. More so, the COM threading models were never any
secret, and there as an MS's document on them (around 1996 IIRC, just after
DCOM appeared in NT4).
| Quote: | For this reason (together with the fact that Unix doesn't
support threading at all),
|
Stupid ancient UNIXen - do not. Good UNIXen - do, and have pthreads
implementation mapped to real kernel threads (like modern Linux does).
| Quote: | most Windows programs remain single-threaded;
programmers acquired the impression that multi-threading under Windows
was such a black art it wasn't worth the effort.
|
Depends on programmer skills in fact. I use threads in Windows in real-world
projects since around 1996, and never had any issues with them, so are the
people I was working with. I never heard about any avoiding threads in Win32
due to them being "too complex". Abusing threads (using a thread when there is
no real need in it) - yes, this is a reality :-)
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| Back to top |
|
|
Logan Shaw
*nix forums Guru
Joined: 21 Feb 2005
Posts: 474
|
| Posted: Mon Feb 13, 2006 5:24 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
Brian Raiter wrote:
| Quote: | My own experience of the term is when it is applied to subroutines
within a program, where it has the meaning: two or more different
threads can safely call the same subroutine in parallel.
Perhaps this distinction is now mainly archaic, but I believe that the
original meaning had little to do with threads or processes. It
specifically meant a function that could be invoked while already in
the middle of an invocation. In other words, if the function called
another function during its execution, could that sub-function
potentionally wind up calling the first function again -- and if so,
would it work correctly or not?
|
I think that's a good point, and it seems worth making the distinction
between that and something that's merely thread-safe. One of the
things that often prevents code from being re-entrant is that it
modifies some global state[1]. Code that modifies state can be made
thread-safe by allocating some thread-local state and ensuring that
an invocation only modifies it's thread's state. However, this
code would not be truly re-entrant, since the one thread could enter
that section of code twice (via a recursive call or something along
those lines).
Perhaps a good example of this is strtok(). It uses some hidden
state, and a thread-safe strtok() could be implemented by making
per-thread storage for that hidden state. That would allow two
threads to call strtok() at once without interfering with each
other, but it wouldn't allow a recursive function to use strtok()
freely. For example, if you wanted to break the string
"a:b:1,2,3:c" down into the form {a, b, {1, 2, 3}, c}, you
might have one strtok() sequence breaking things down by colons
and another strtok() sequence breaking things down by commas
nested inside the first strtok() sequence. For this to work
within a single thread, a thread-safe strtok() wouldn't be
sufficient: you'd need a re-entrant one.
- Logan
[1] Or other state which isn't specific to the call to the code.
That is, it wouldn't necessarily have to be global as long as
two invocations can stomp on each other's state. |
|
| Back to top |
|
|
Alexei A. Frounze
*nix forums Guru Wannabe
Joined: 10 Apr 2005
Posts: 243
|
| Posted: Mon Feb 13, 2006 8:49 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:84THf.302094$D47.23800@fe3.news.blueyonder.co.uk...
....
| Quote: | When a thread of a Windows program calls the Win32 API function
CreateWindow (or CreateWindowEx), a handle is returned to the created
window. This handle is used for all subsequent interaction with the window
via the Windows API.
For a long time (several years, I recall), people were trying to do window
operations using a multi-threaded program and wondering why it didn't
work. Eventually, Microsoft came clean, and admitted that only the thread
that created the window could subsequently manipulate that window (in
particular, only that thread can receive messages from the window).
|
I think I had that same problem a few years ago when I wrote my first couple
of multithreaded GUI apps for windows. Surprisingly, I either hit an
exception at the point of accessing an MFC object from a different thread or
something of that sort and right at that point I found a comment in the MFC
source saying "don't do that". To me it was also unexpected, probably I
didn't know where in the documentation I should have read about what to
expect if I try doing that. I had to implement message communication between
the two threads to do something in one on behalf of the other.
| Quote: | For this reason (together with the fact that Unix doesn't support
threading at all), most Windows programs remain single-threaded;
programmers acquired the impression that multi-threading under Windows was
such a black art it wasn't worth the effort.
|
I'm not sure about that. To me it seems that some (or many?) people either
don't think about multithreading and continue to write code in the style of
70s or have hard time understanding the entire concept and its implications
w/o connection to a particular OS.
Alex |
|
| Back to top |
|
|
David Schwartz
*nix forums Guru
Joined: 26 Feb 2005
Posts: 914
|
| Posted: Mon Feb 13, 2006 10:01 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:84THf.302094$D47.23800@fe3.news.blueyonder.co.uk...
| Quote: | For a long time (several years, I recall), people were trying to do window
operations using a multi-threaded program and wondering why it didn't
work. Eventually, Microsoft came clean, and admitted that only the thread
that created the window could subsequently manipulate that window (in
particular, only that thread can receive messages from the window).
|
I don't remember this ever being a secret. It was always clear that each
thread had its own event queue. There were even functions to send messages
to a particular thread's queue. It's not that only that thread can receive
messages from the window, it's that windows messages are routed to that
thread's queue.
| Quote: | For this reason (together with the fact that Unix doesn't support
threading at all), most Windows programs remain single-threaded;
programmers acquired the impression that multi-threading under Windows was
such a black art it wasn't worth the effort.
|
I totally disagree. The vast majority of Windows programs these days are
multi-threaded, and in many ways the WIN32 API makes this much easier to do
than the UNIX API does. Although, of course, it does have its problems.
You are correct, however, about terrible Microsoft documentation.
Pthreads has its issues too, but Microsoft has forced developers to guess an
awful lot more than they should have.
DS |
|
| Back to top |
|
|
David Schwartz
*nix forums Guru
Joined: 26 Feb 2005
Posts: 914
|
| Posted: Mon Feb 13, 2006 10:04 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
"Alexei A. Frounze" <alexfru@chat.ru> wrote in message
news:45avjbF5pnlhU1@individual.net...
| Quote: | For this reason (together with the fact that Unix doesn't support
threading at all), most Windows programs remain single-threaded;
programmers acquired the impression that multi-threading under Windows
was such a black art it wasn't worth the effort.
I'm not sure about that. To me it seems that some (or many?) people either
don't think about multithreading and continue to write code in the style
of 70s or have hard time understanding the entire concept and its
implications w/o connection to a particular OS.
|
A lot of Windows software sucks because programmers are unwilling to
learn how to correctly program to the modern WIN32 API. The biggest problem
is people who do things the UNIX way with the minimal changes needed to get
it to seem to work on Windows. The second-biggest problem is people who
still do horrible things you had to do back on Windows 3.1 thinking that you
still have to.
Today, the WIN32 API is suprisingly clean and surprisingly friends to
threading. A lot of things you have to go out of your way to get even close
to right on pthreads are trivial to do on Windows. (Not that it doesn't have
its own problems, of course.)
Perhaps as more programmers start to write multi-threaded programs on
UNIXes (since it is now very stable on most UNIXes people still care about),
WIN32 will benefit. If nothing else, multi-core CPUs should force people to
multi-thread because you have to if you want to get what the hardware is
capable of.
DS |
|
| Back to top |
|
|
Chris Thompson
*nix forums addict
Joined: 09 Mar 2005
Posts: 57
|
| Posted: Mon Feb 13, 2006 4:42 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
In article <dsl62m$1hvr$1@gavrilo.mtu.ru>,
Maxim S. Shatskih <maxim@storagecraft.com> wrote:
| Quote: | I'm not sure what 'reentrant' means here. AFAIK a program code segment
is usually reentrant in that it cannot normally be written to - so
I'm against the whole word of ''reentrant". It is, in fact, something from the
old time of MS-DOS add-ons which tried to do multitasking from this pathetic
OS.
|
MS-DOS? That's practically yesterday! We were talking about "reeentrant" and
"serially reusable" load modules back in OS/360, and it probably wasn't a
new term then.
--
Chris Thompson
Email: cet1 [at] cam.ac.uk |
|
| Back to top |
|
|
Nicholas Sherlock
*nix forums addict
Joined: 02 Mar 2005
Posts: 71
|
| Posted: Mon Feb 13, 2006 11:31 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
Maxim S. Shatskih wrote:
| Quote: | Please note where and when the Win32 APIs are not thread-safe.
Maxim, I get the impression that you know a lot about the Win32 API, so
I'm surprised by your question.
I'm surprised by your answer. Can you _name the exact Win32 API routines by
Microsoft_ which do not support multithreading?
|
There are a few, I think, but they're not what I'd call "Core APIs". The
ImageHlp library doesn't support multi-threading.
Cheers,
Nicholas Sherlock |
|
| Back to top |
|
|
James Harris
*nix forums beginner
Joined: 07 Jun 2005
Posts: 8
|
| Posted: Tue Feb 14, 2006 10:04 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
"Chris Thompson" <cet1@cus.cam.ac.uk> wrote in message
news:dsqct8$q1r$1@gemini.csx.cam.ac.uk...
| Quote: | In article <dsl62m$1hvr$1@gavrilo.mtu.ru>,
Maxim S. Shatskih <maxim@storagecraft.com> wrote:
I'm not sure what 'reentrant' means here. AFAIK a program code
segment
is usually reentrant in that it cannot normally be written to - so
I'm against the whole word of ''reentrant". It is, in fact, something
from the
old time of MS-DOS add-ons which tried to do multitasking from this
pathetic
OS.
MS-DOS? That's practically yesterday! We were talking about
"reeentrant" and
"serially reusable" load modules back in OS/360, and it probably
wasn't a
new term then.
|
That's where I first came across the term. It was a long time ago. IIRC
it would apply to any module that did not modify part of itself. |
|
| Back to top |
|
|
Maxim S. Shatskih
*nix forums addict
Joined: 02 Apr 2005
Posts: 55
|
| Posted: Wed Feb 15, 2006 1:02 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
| Quote: | There are a few, I think, but they're not what I'd call "Core APIs". The
ImageHlp library doesn't support multi-threading.
|
Is it documented? Can I use apartment threading there - i.e. many threads, but
the entity is only used by the thread which created it?
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| Back to top |
|
|
50295@web.de
*nix forums beginner
Joined: 09 Feb 2005
Posts: 32
|
| Posted: Wed Feb 15, 2006 2:07 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
Rather than start a new thread, I though it better to add a question
here since the thread has already gone a bit OT alteady  (by the
way, thanks to everyone for the naswers).
Just a minor point: I was pondering on the nature of the "conversation"
(or should I say instructions) the driver has with the controller. Is
it correct to term these commands microcode?
Thanks,
- Olumide |
|
| Back to top |
|
|
Brian Inglis
*nix forums beginner
Joined: 16 Feb 2005
Posts: 22
|
| Posted: Wed Feb 15, 2006 11:55 am Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
On 14 Feb 2006 18:07:26 -0800 in comp.unix.internals, "Olumide"
<50295@web.de> wrote:
| Quote: | Rather than start a new thread, I though it better to add a question
here since the thread has already gone a bit OT alteady (by the
way, thanks to everyone for the naswers).
Just a minor point: I was pondering on the nature of the "conversation"
(or should I say instructions) the driver has with the controller. Is
it correct to term these commands microcode?
|
No, they would be device commands and responses.
Some organizations (IBM at least) consider any low level code below
the architectural interface (e.g. on an ethernet card or disk drive)
to be microcode, as opposed to the more widespread view of microcode
as hardwired code used to execute architectural instructions within a
CPU.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply |
|
| Back to top |
|
|
50295@web.de
*nix forums beginner
Joined: 09 Feb 2005
Posts: 32
|
| Posted: Wed Feb 15, 2006 2:34 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
Brian Inglis wrote:
| Quote: | No, they would be device commands and responses.
Some organizations (IBM at least) consider any low level code below
the architectural interface (e.g. on an ethernet card or disk drive)
to be microcode, as opposed to the more widespread view of microcode
as hardwired code used to execute architectural instructions within a
CPU.
|
Thanks Brian. I'm now of the view that device driver commands to the
controller are not microcode -- at least in the case of memory-mapped
IO, since it by definition does not distinguish between controller
registers and memory locations. |
|
| Back to top |
|
|
Nick Roberts
*nix forums beginner
Joined: 12 Feb 2006
Posts: 5
|
| Posted: Wed Feb 15, 2006 11:14 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
Maxim S. Shatskih wrote:
| Quote: | I'm surprised by your answer. Can you _name the exact Win32 API routines by
Microsoft_ which do not support multithreading?
|
Well, no I cannot, and I have to concede defeat as such :-)
| Quote: | Stupid ancient UNIXen - do not. Good UNIXen - do, and have pthreads
implementation mapped to real kernel threads (like modern Linux does).
|
I am not an expert on pthreads, but my impression is that this facility
is really rather limited. I have heard that you cannot use the semaphore
facility without running as root, and that you are limited to 32 semaphores.
| Quote: | Depends on programmer skills in fact. I use threads in Windows in real-world
projects since around 1996, and never had any issues with them, so are the
people I was working with.
|
You really never had /any/ issues with them?
| Quote: | Abusing threads (using a thread when there is
no real need in it) - yes, this is a reality 
|
I'm interested in this point. When you say "using a thread when there is
no real need", do you mean something really daft (e.g. thread B cannot
start any of its work until thread A has completed all of its work) or
do you mean situations that might be considered 'overkill' (e.g. a video
game where every moving object has a thread, so requiring hundreds or
thousands of threads)?
I'm curious about this, because there are programming languages that
could be implemented in a way that tends to use lots of threads, even
when sometimes they are not really necessary. For example, a (modified)
Smalltalk implementation might implement every object as a thread, apart
from some optimisation for primitive operations.
While I have the attention of Windows expert, I'd also like to ask about
the Win32 memory model. I have always found it confusing as to which
parts of the map correspond to what, and how efficient memory management
should be achieved (at the machine code level, not C).
How should a full (generational) garbage collection scheme be
approached? Remember that full GC requires that blocks can be moved
around in memory at any time (to make a contiguous space for a new
allocation). It has to be thread-safe, and it has to be able to cope
with lots of small blocks mixed with a few large blocks. It must be 100%
non-leaking, and it must behave gracefully when memory limitations are
reached. Can this be done under Win32?
Sorry to go off topic here, but I'm eager to take the opportunity!
Thanks in advance.
--
Nick Roberts |
|
| Back to top |
|
|
Maxim S. Shatskih
*nix forums addict
Joined: 02 Apr 2005
Posts: 55
|
| Posted: Wed Feb 15, 2006 11:21 pm Post subject:
Re: Are Device Drivers Reentrant -- or Daemons?
|
|
|
| Quote: | do you mean situations that might be considered 'overkill' (e.g. a video
game where every moving object has a thread, so requiring hundreds or
thousands of threads)?
|
I mean overkill. For instance, using thread instead of the good old nonblocking
socket :)
| Quote: | While I have the attention of Windows expert, I'd also like to ask about
the Win32 memory model.
|
Very similar to UNIX one. The kernel even supports fork(), which is used in
Microsoft Interix (UNIX emulation layer for Windows, rather rich).
| Quote: | How should a full (generational) garbage collection scheme be
approached?
|
This is .NET, and not Windows. The details of .NET garbage collector can be
found on msdn.microsoft.com - just google for "CLR garbage collector" or such.
| Quote: | reached. Can this be done under Win32?
|
Yes it can. No my area of expertise though (it is .NET), but well-documented.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Nov 22, 2008 1:32 pm | All times are GMT
|
|
Low Interest Credit Card | Online Gift Shopping | Loans | Remortgages | Loans
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Programming
»
Unix internals
