to allow software to indicate to the hardware a cache line is no longer required for further storage update , an instruction can be provided , with a way to indicate the logical address , as suited to a specific architecture . this is done with a new opcode or a new variation of an existing cache management instruction using unused fields or code - points . specific instructions which implement this invention are expected to be used in device drivers , operating system code or any application that uses common parameter blocks or semaphore blocks . the intention of this provision is that the software code will treat this as a “ done with store to this line ” instruction , now simply called “ demote instruction ”, at the end of its last storage updating instruction . it should be used for lines that contain highly utilized data across various processes that are executing in different processors and most likely at different times . one typical software example may be on the management of a cache line that contains various semaphore locks needed for multiprocessor handling . the effect of the software using this provision will be to obtain or release a software lock managed in a cache line , and then demote the line actively . by releasing the line actively , other processes can proceed more quickly to either obtain or release the same lock or other locks managed within the same cache line . an important thing is that the software application knows that this is the last point of update until some period of time later . if the software requires an update to the line soon after a “ demote ”, it would instead be bad for performance , since then the processor will take time to regain the exclusive rights . let &# 39 ; s describe how this instruction is implemented in computer system with a cache hierarchy as illustrated in fig1 . this figure , and subsequent fig2 - 5 , illustrates a bi - nodal system where the storage controller ( sc ) is made up of 2 different physical node controllers sc 0 101 and sc 1 102 , each having 3 processors 103 - 105 or 106 - 108 attached . fig1 indicates a typical initial state where processor 103 ( cpy ) already owns the exclusive rights to a cache line a . fig2 illustrates that when processor 107 ( cpx ) requests to have exclusive rights to same cache line a , ( e . g . when it is executing a “ store ” instruction and needs store access ) while processing a storage update instruction , the wait on getting a confirmation on the cross interrogate ( xi ) from the current owning processor 103 ( cpy ) delays this requesting processor 107 ( cpx ) from being able to start any storage update to the line a . the steps 1 - 10 are shown in fig2 . with the provision of a “ demote ” instruction , instead of having to take up the delay on the xi acknowledgement , the scs 101 or 102 would have already updated its directory to show that no processor is currently owning the line exclusively , and thus can return the line a exclusively to processor 107 cpx when processor 107 cpx requests for it in a very timely manner . this is shown in fig3 and 4 . in fig3 , when the application running on processor 103 cpy decides to “ demote ” the cache line , processor 103 cpy will send a request to sc 0 101 to demote line a ( 1 ). ( there will be a decoding and execution of a program instruction calling for such a demotion ) once the demote request is received , the sc 0 101 will process the request as if a “ non - existing ” processor is requesting line a exclusively . it will start up the lookup in its directory , send a cross interrogate to processor 103 cpy to request a release on exclusive rights ( 2 ). if processor 103 cpy still have storage update to that line pending in its pipeline , it can reject the cross interrogate . the sc 0 101 will in turn repeat the cross interrogate until pending stores in processor 103 cpy are drained . when there is no pending stores for line a existing in processor 103 cpy , processor 103 cpy at this time should naturally be accepting the release request . processor 103 cpy will update its directory with no more exclusive rights and send back an acknowledgement to sc 0 101 ( 3 ). once the acknowledgement is received , the sc 0 101 will update its directory update to indicate that line a is now exclusive to “ no one ” ( 4 ). the software demote process is thus accomplished . this state of exclusive to no one is equivalent to a shared ( or read - only ) state with respect to how if affect exclusive xi activities concerning this line . now , as seen in fig4 , if another processor 107 cpx requests line a exclusively ( 1 ), the sc 1 102 can quickly request the line exclusively from sc 0 101 ( 2 - 4 ), and then reply to the requesting processor 107 cpx with an exclusive response ( 5 - 6 ) without acquiring any delay for cross interrogation towards processor 103 cpy . this reduction of delay could be even more apparent in a system if the storage controllers for nodes 101 , 102 are on a different chip ( s ) than the processors , where the cross - chip communication is now removed . to further describe a variant implementation of this demote instruction , we will illustrate with a system where there is one private level 2 cache ( l2 ) per processor . this is shown in fig5 . each processor 103 - 108 in this system has a private l2 200 . in this design , when processor 103 cpy sends a demote request to its private l2 200 l 2 y ( 1 ), the l2 will lookup its directory , and then send a release exclusive cross interrogate back into the processor 103 cpy ( 2 ). if the load store unit ( lsu ) inside the processor 103 cpy still has storage update to that line pending in its pipeline , it can reject the cross interrogate . the l2 200 l 2 y will in turn repeat the cross interrogate until pending stores in processor 103 cpy are drained . when there is no pending stores for line a , the lsu inside the processor 103 cpy will process the interrogate request , remove its directory status of exclusive ownership , and acknowledge to l2 200 l 2 y that this is done ( 3 ). this private l2 200 l 2 y will drain any pending store to this line a , then also update its directory to indicate no exclusive ownership ( 4 ), and send a demote request to the sc 0 101 ( 5 ). upon receiving the demote request , sc 0 101 will update its directory to indicate the line a is now exclusive to “ no one ” ( 6 ). with this illustration , it will be appreciated that this function can be implemented with various systems having a different cache hierarchy or topology than that illustrated . because these can be implemented by those skilled in the art after learning of this teaching , all their variants are not specifically shown . fig6 illustrates how such an instruction is processed within a microprocessor core . for this description , only 3 of the key units idu 301 ( instruction dispatch unit ), fxu 302 ( fixed point unit ), and lsu 303 ( load store unit ) are depicted as part of the microprocessor cp 300 . during hardware execution of this instruction , the microprocessor pipeline will execute this instruction as a one cycle superscalar instruction that performs no architectural updates . all the work is to be performed by the cache subsystem . for an in - order microprocessor cp 300 , when the “ demote instruction ” is dispatched from the instruction dispatch unit idu 301 , the logical address calculated according to the instruction format and a decode of such instruction indicating a demote operation will be sent from idu 301 to lsu 303 ( arrow 1 ). in parallel , idu 301 will send the opcode to fxu 302 ( arrow 2 ) which will complete the instruction if this is the next to complete without waiting for any acknowledgement or doing any architectural update . lsu 303 will obtain the absolute address used in cache management by either looking up the address translation of the logical address sent from idu 301 in its translation lookaside buffer ( tlb ) 310 , or obtain a translation result through a dynamic translation process . once the absolute address is obtained ( arrow 4 ), it will arm the absolute address and a demote command in one of its available fetch address register ( far ) 312 . the demote command will be a predefined interface value on the request bus ( arrow 6 ) to the storage controller ( sc ) indicating a “ demote ” is to be performed . the lsu &# 39 ; s 303 control logic 313 will hold on to the demote request , and wait until all prior instructions complete before it send the demote request and address to the sc ( arrow 6 ). this is done by monitoring pipeline flushing interface from the fxu 302 which controls instruction completion in this example . it is important that the demote request is not sent under an incorrectly predicted branch path , or if any older instruction does not successfully complete due to processor pipeline flushing conditions . otherwise , an unnecessary performance penalty may be incurred . in an out of order microprocessor , due to the nature of the design , the actual launch of the demote request from the lsu makes use of a tag . to fit into an out of order design , the demote request sitting in the far register is tagged with an instruction id , and only launched when the global completion logic determines that this instruction id is being completed . an alternative design , not specifically shown in fig5 but illustrated thereby , will have the demote request be written into a store queue entry ( instead of a far register entry ) at 312 . by doing so , since stores have to be completed and processed in order for machines requiring a strongly - ordered memory model , the store queue logic at 312 will tagged its entries with instruction ids and receive instruction completion ordering from the global completion logic . the store queue logic can then precisely send the demote request ( through the far logic ) without being premature . additionally , any pending stores prior to the demote instruction will naturally be drained out of its pipeline before a demote request is sent . this helps in reducing the chance that the lsu needs to reject the demote cross interrogate when sent by the storage controller , or a private l2 if installed . as illustrated , the present invention can help improve system performance by carefully inserting “ demote ” instructions in software code , with a hardware provision of such mechanism . it requires thoughtful implementation in software , firmware , together with hardware to be effective . the flow diagrams depicted herein are just examples . there may be many variations to these diagrams or the steps ( or operations ) described therein without departing from the spirit of the invention . for instance , the steps may be performed in a differing order , or steps may be added , deleted or modified . all of these variations are considered a part of the claimed invention . while the preferred embodiment to the invention has been described , it will be understood that those skilled in the art , both now and in the future , may make various improvements and enhancements which fall within the scope of the claims which follow . these claims should be construed to maintain the proper protection for the invention first described .