StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
15401929
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-03-14T05:33:43.850
FavoriteCount
0
LastActivityDate
2013-03-14T06:08:15.813
LastEditDate
2013-03-14T06:08:15.813
LastEditorUserId
2168377
OwnerUserId
2168377
ParentId
7376286
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
The suggestion to avoid weak references does not solve the race issue. <pre><code>T1 operator new, create object, references: 1 T1 passes interface object reference to T2, thinking it can "share" ownership T1 suspends T2 resumes T2 QueryInterface T2 suspends before InterlockedIncrement, references: 1 T1 resumes T1 Calls Release T1 suspends between InterlockedDecrement and operator delete, references: 0 T2 resumes, InterlockedIncrement occurs, references 1 T2 suspends T1 resumes, operator delete executes, references 1 !!! T1 suspends T2 resumes T2 Any reference to the interface is now invalid since it has been deleted with reference count 1. </code></pre> This is solvable in the COM server. The COM client, however, should not depend upon the server preventing this race condition. Therefore, COM clients MUST NOT share interface objects between threads. The only thread which should be allowed to access the interface object, is the ONE thread which currently "owns" the interface object. T1 should NOT have called Release. Yes, it could have called AddRef prior to passing the interface object to T2. But that may not solve the race, only move it someplace else. The best practice is to always maintain the concept of one-interface-object, one-owner. If the COM server wishes to support the concept that two (or more) interfaces can reference some shared server-internal state, the COM server should advertise the contract by supplying a CreateCopyOfInstance method and manage contention, internally. There are, of course, examples of servers which handle this sort of "fan-out". Take a look at the persistent storage interfaces from Microsoft. There, the interfaces do NOT "fan-out" .. each interface should be owned by a single user (thread/process/whatever) and the "fan-out" is managed, internally, by the server, with methods provided to the COM clients to control some facets of the contention issues. Microsoft's COM servers must, therefore, address the race conditions as part of their contracts to their clients.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. PODoes IUnknown::QueryInterface() increment the reference count?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USuser2168377
UserOwnerUserId
1. USuser2168377
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.